Subject: Re: [bitcoin-dev] [Lightning-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment

From: Peter Todd <[email-masked]>
Date: Tue, 30 Jan 2024 08:40:41 +0000

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 <[email-masked]> 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