Subject: Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

From: Antoine Riard <[email-masked]>
Date: Fri, 3 Nov 2023 05:25:24 +0000

> To be clear, are you talking about anchor channels or non-anchor channels?
> Because in anchor channels, all outputs other than the anchor outputs
provided
> for fee bumping can't be spent until the commitment transaction is mined,
which
> means RBF/CPFP isn't relevant.

I think the distinction is irrelevant here as pre-anchor channel if I have
one spendable HTLC output spend and I gain knowledge of my counterparty
commitment transaction from networks mempools, the spend is malleable and
can be used as a CPFP. If you assume anchor channels, you have 2 anchor
outputs as long both parties have balance outputs or pending HTLCs.

Though pre-anchor, legacy channels the counterparty commitment transaction
will have to be attached with a fee under min mempool fee for the
replacement cycling to happen, and let network congestion happen.

I think the more interesting case is a future world with package relay
deployed at the p2p level and anchor output on the lightning-side. Here the
most advanced replacement as illustrated in the test can happen (where
commitment has an anchor output - see L125).

Best,
Antoine

Le jeu. 2 nov. 2023 à 06:26, Peter Todd <[email-masked]> a écrit :

> On Thu, Nov 02, 2023 at 05:24:36AM +0000, Antoine Riard wrote:
> > Hi Peter,
> >
> > > So, why can't we make the HTLC-preimage path expire? Traditionally,
> we've
> > tried
> > > to ensure that transactions - once valid - remain valid forever. We do
> > this
> > > because we don't want transactions to become impossible to mine in the
> > event of
> > > a large reorganization.
> >
> > I don't know if reverse time-lock where a lightning spending path becomes
> > invalid after a block height or epoch point solves the more advanced
> > replacement cycling attacks, where a malicious commitment transaction
> > itself replaces out a honest commitment transaction, and the
> > child-pay-for-parent of this malicious transaction is itself replaced out
> > by the attacker, leading to the automatic trimming of the malicious
> > commitment transaction.
>
> To be clear, are you talking about anchor channels or non-anchor channels?
> Because in anchor channels, all outputs other than the anchor outputs
> provided
> for fee bumping can't be spent until the commitment transaction is mined,
> which
> means RBF/CPFP isn't relevant.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>