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>