MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <ZTMWrJ6DjxtslJBn@petertodd.org>
 <CALZpt+GQ9g-uwAGYogdaJcinVHRxs4=67hML78KbramJg=davA@mail.gmail.com>
 <ZUNBHsw2BldPLvPc@petertodd.org>
In-Reply-To: <ZUNBHsw2BldPLvPc@petertodd.org>
From: Matt Morehouse <mattmorehouse@gmail.com>
Date: Thu, 2 Nov 2023 17:07:39 +0000
Message-ID: <CAGyamEXYJN0qGKzWPsN8-T1URqmeTbUH7JJjwuFKMHByCwEG3A@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: security@ariard.me, "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making
 HTLCs Safer by Letting Transactions Expire Safely
Precedence: list

On Thu, Nov 2, 2023 at 6:27=E2=80=AFAM 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, w=
e've
> > tried
> > > to ensure that transactions - once valid - remain valid forever. We d=
o
> > this
> > > because we don't want transactions to become impossible to mine in th=
e
> > event of
> > > a large reorganization.
> >
> > I don't know if reverse time-lock where a lightning spending path becom=
es
> > 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 o=
ut
> > 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 pro=
vided
> 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