From antoine.riard at gmail.com  Fri Nov  3 05:25:24 2023
From: antoine.riard at gmail.com (Antoine Riard)
Date: Fri, 3 Nov 2023 05:25:24 +0000
Subject: [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making
 HTLCs Safer by Letting Transactions Expire Safely
In-Reply-To: <ZUNBHsw2BldPLvPc@petertodd.org>
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <ZTMWrJ6DjxtslJBn@petertodd.org>
 <CALZpt+GQ9g-uwAGYogdaJcinVHRxs4=67hML78KbramJg=davA@mail.gmail.com>
 <ZUNBHsw2BldPLvPc@petertodd.org>
Message-ID: <CALZpt+GBcqquPtf0YB07Rcy2OS0kUhv86s6g=69VrfSE72cYJQ@mail.gmail.com>

> 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 <pete at petertodd.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231103/12097818/attachment-0001.html>