On Tue, Jan 30, 2024 at 05:07:16AM +0000, ZmnSCPxj wrote: > 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.
You make a good point that Lightning channels *should* work that way. But even right now they do not: Lightning commitment transactions pay a fixed, generally low, fee-rate just high enough to propagate (and often lower) and are expected to be brought up to full fee-rate via the anchor outputs. Either side can pay the fees using the anchor outputs. And in practice, it's quite common for the initiator to *not* pay the supermajority of the fees. Furthermore, the proposals floating around for V3 transactions and Lightning is to double-down on this design, with the commitment transaction paying no fees at all and anchor outputs (and CPFP) being always used. > 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. Again, Lightning channels *right* now work this way too. I personally have done steps #1 to #5 the other day on the same laptop I'm writing this email on. Due to a glitch in channel closing, the cooperative close failed, and at the moment the recipient has a 10sat/VB commitment transaction with a fee below most mempools' minrelayfee. Their balance was ~2 million sats, and my local balance was just ~20k sats, and the commitment transaction was signed with the default 10sat/vB fee, which is well below the minrelayfee, let alone competitive. If the receipient wants their ~2 million sats any time soon they're going to have to CPFP the commitment transaction to get it up to about 30sat/vB, at which point they've paid the supermajority of the cost even though they're the receipient. Personally, I've shut down that node for good (I archived .lnd) and I'll check back in a month or two to see if they ever get their funds. > This is why the initial design for openv1 is "initiator pays". ...and that design clearly went out the window with anchor channels. > 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. No, RBF channels have nothing to do with whether or not the "initiator pays". If you want to have the RBF concept, and initator pays, you just need to negotiate a minimum fee rate that you take out of the initiators balance. That aspect of the design is orthogonal to how exactly the rest of the fees are paid, and the concept of negotiating a minimum fee for the commitment transaction to pay is relevant to all forms of anchor channels too. > 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. ...and no-one is proposing that variation for the obvious reason that the receipient has no incentive not to use the full fee-rate every time. Indeed, a hypothetical CPFP version of this variation would have the exact same incentive issue. -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
