From pete at petertodd.org Thu Nov 2 06:26:38 2023 From: pete at petertodd.org (Peter Todd) Date: Thu, 2 Nov 2023 06:26:38 +0000 Subject: [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely In-Reply-To: <CALZpt+GQ9g-uwAGYogdaJcinVHRxs4=67hML78KbramJg=davA@mail.gmail.com> References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com> <ZTMWrJ6DjxtslJBn@petertodd.org> <CALZpt+GQ9g-uwAGYogdaJcinVHRxs4=67hML78KbramJg=davA@mail.gmail.com> Message-ID: <ZUNBHsw2BldPLvPc@petertodd.org> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231102/8a456ef3/attachment-0001.sig>