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>