Sent with Proton Mail secure email.
On Tuesday, January 30th, 2024 at 4:38 AM, Peter Todd <p...@petertodd.org>
wrote:
> On Tue, Jan 30, 2024 at 04:12:07AM +0000, ZmnSCPxj wrote:
>
> > Peter Todd proposes to sign multiple versions of offchain transactions at
> > varying feerates.
> > However, this proposal has the issue that if you are not the counterparty
> > paying for onchain fees (e.g. the original acceptor of the channel, as per
> > "initiator pays" principle), then you have no disincentive to just use the
> > highest-feerate version always, and have a tiny incentive to only store the
> > signature for the highest-feerate version to reduce your own storage costs
> > slightly.
>
>
> You are incorrect. Lightning commitments actually come in two different
> versions, for the local and remote sides. Obviously, I'm proposing that fees
> be
> taken from the side choosing to sign and broadcast the transaction. Which is
> essentially no different from CPFP anchors, where the side choosing to get the
> transaction mined pays the fee (though with anchors, it is easy for both sides
> to choose to contribute, but in practice this almost never seems to happen in
> my experience running LN nodes).
There is a reason why I mention "initiator pays", and it is because the channel
opener really ought to pay for onchain fees in general.
For example, I could mount the following attack:
1. I already have an existing LN node on the network.
2. I wait for a low-feerate time.
3. I spin up a new node and initiate a channel funding to a victim node.
4. I empty my channel with the victim node, sending out my funds to my
existing LN node.
5. I retire my new node forever.
This forces the victim node to use its commitment tx.
If the onchain fee for the commitment tx is paid for by who holds the
commitment tx (as in your proposal) then I have forced the victim node to pay
an onchain fee.
This is why the initial design for openv1 is "initiator pays".
In the above attack scenario, the commitment tx held by the victim node, under
"initiator pays", has its onchain fee paid by me, thus the victim is not forced
to pay the unilateral close fee, I am the one forced to pay it.
They do still need to pay fees to get their now-onchain funds back into
Lightning, but at least more of the onchain fees (the fees to unilaterally
close the channel with the now-dead node) is paid by the attacker.
On the other hand, it may be possible that "initiator pays" can be dropped.
In this attack scenario, the victim node should really require a non-zero
reserve anyway that is proportional to the channel size, so that the attacker
needs to commit some funds to the victim until the victim capitulates and
unilaterally closes.
In addition, to repeat this attack, I need to keep opening channels to the
victim and thus pay onchain fees for the channel open.
So it may be that your proposal is sound; possibly the "initiator pays"
advantage in this attack scenario is small enough that we can sacrifice it for
multi-fee-version.
I should note that under Decker-Russell-Osuntokun the expectation is that both
counterparties hold the same offchain transactions (hence why it is sometimes
called "LN-symmetry").
However, there are two ways to get around this:
1. Split the fee between them in some "fair" way.
Definition of "fair" wen?
2. Create an artificial asymmetry: flip a bit of `nSequence` for the
update+state txes of one counterparty, and have each side provide signatures
for the tx held by its counterparty (as in Poon-Dryja).
This lets you force that the party that holds a particular update+state tx
is the one that pays fees.
> > In addition, it is also incentive-incompatible for the party that pays
> > onchain fees to withhold signatures for the higher-fee versions, because if
> > you are the party who does not pay fees and all you hold are the complete
> > signatures for the lowest-fee version (because the counterparty does not
> > want to trust you with signatures for higher-fee versions because you will
> > just abuse it), then you will need anchor outputs again to bump up the fee.
>
>
> That is also incorrect. If the protocol demands multiple fee variants exist,
> the state of the lightning channel simply doesn't advance until all required
> fee-variants are provided. Withholding can't happen any more than someone
> could
> "withhold" a state by failing to provide the last byte of a commitment
> transaction: until the protocol state requirements have been fufilled in full,
> the previous state remains in effect.
No, I am referring to a variation of your proposal where the side paying the
fees in "initiator pays" gets full signatures for all feerate-versions but the
other side gets only the full signatures for the lowest-fee version.
If you can build the multi-version proposal with both sides contributing fees
or with the one exiting the channel paying the fee, then this variation is
unnecessary and you can ignore this paragraph.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
