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

From: Antoine Riard <antoine.riard@gmail•com>
To: Matt Morehouse <mattmorehouse@gmail•com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	"lightning-dev\\\\@lists.linuxfoundation.org"
	<lightning-dev@lists•linuxfoundation.org>,
	security@ariard•me
Subject: Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
Date: Fri, 3 Nov 2023 05:27:54 +0000	[thread overview]
Message-ID: <CALZpt+EhE=06bg8eph0bJ+bGvoJFSCEkXwmegbUNQcLSr_ACuw@mail.gmail.com> (raw)
In-Reply-To: <CAGyamEXYJN0qGKzWPsN8-T1URqmeTbUH7JJjwuFKMHByCwEG3A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3461 bytes --]

> The idea with package relay is that commitment transaction fees will
> be zero and that fees will always be paid via CPFP on the anchor
> output.

Yes, even if multiple commitment transactions are pre-signed with a RBF
range of more than zero, an attacker can always select the lowest fees
pre-signed states and adjust in consequence the CPFP paid, and then evict
out the bumping CPFP.

Le jeu. 2 nov. 2023 à 17:07, Matt Morehouse <mattmorehouse@gmail•com> a
écrit :

> On Thu, Nov 2, 2023 at 6:27 AM Peter Todd via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> > 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.
>
> IIUC, Antoine is talking about a cycling attack of the commitment
> transaction itself, not the HTLC transactions.  It seems possible for
> future (ephemeral) anchor channels in a world with package relay.
>
> The idea with package relay is that commitment transaction fees will
> be zero and that fees will always be paid via CPFP on the anchor
> output.
>
> Consider this scenario:  Mallory1 -> Alice -> Mallory2.
> Mallory2 claims an HTLC from Alice off chain via the preimage.  Alice
> attempts to claim the corresponding HTLC from Mallory1, but Mallory1
> refuses to cooperate.  So Alice publishes her commitment transaction
> along with a CPFP on the anchor output.  Mallory1 publishes her
> competing commitment transaction with a higher CPFP fee on the anchor
> output, thereby replacing Alice's package in the mempool.  Mallory1
> then replacement-cycles the anchor output child transaction, causing
> her commitment transaction to lose its CPFP and the package feerate to
> go to zero, which is below the minimum relay fee.  Thus, Mallory1's
> commitment transaction is also evicted from the mempool.  Mallory1
> repeats this process every time Alice broadcasts her commitment, until
> the HTLC timeout expires.  At that point the preimage path becomes
> unspendable, and Mallory1 can claim the HTLC via timeout at her
> leisure.
>
> >
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4532 bytes --]