MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <7ED2BCD8-BAE3-48E3-9749-A396F3724B6E@petertodd.org>
 <CALZpt+GsRfHvABjhkX=eN_1viVw8Jos4=+sBd7vWQJ_VxNta8g@mail.gmail.com>
 <ZTJays5mDFvDqkkB@petertodd.org>
In-Reply-To: <ZTJays5mDFvDqkkB@petertodd.org>
From: Jochen Hoenicke <hoenicke@gmail.com>
Date: Fri, 20 Oct 2023 13:18:46 +0200
Message-ID: <CANYHNmLb3_JRSu1Di4LNtVs7Z=jsPQ0T+-0LznE9Ma++Xiqbew@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232
 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
Precedence: list

I found the original explanation a bit confusing.  As I understand it,
the attack starts by double-spending the timeout HTLC transaction of
the victim with a pre-image revealing HTLC transaction.  This itself
is not an attack: the victim can then use the pre-image to receive its
incoming HTLC safely, because its timeout hasn't expired yet.  The
trick is now that the attacker double-spends their own transaction
before it hits the chain (the third transaction only double-spends
some attacker controlled input used also by the pre-image HTLC
transaction).  In ideal condition, the pre-image transaction is never
seen by the victim and the victim still doesn't know the pre-image.
The attacker may only attack the mempool of the mining nodes. The
victim may not even know that their transaction was replaced and are
only confused why it didn't get mined.

On Fri, 20 Oct 2023 at 12:47, Peter Todd via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Tue, Oct 17, 2023 at 02:11:20AM +0100, Antoine Riard wrote:
> > > I think if you want people to understand this exploit, you need to
> > explain in more detail how we have a situation where two different parties
> > can spend the same HTLC txout, without the first party having the right to
> > spend it via their knowledge of the HTLC-preimage.
> >
> > If I'm correctly understanding your question, you're asking why we have a
> > situation where the spend of a HTLC output can be in competition between 2
> > channel counterparties.
>
> No, you are not correctly understanding it.
>
> It's obvious that an HTLC output can be in competition between 2 different
> parties. Obviously, the HTLC-preimage doesn't expire. The problem is you
> haven't explained why the party with the HTLC pre-image should not *remain* the
> party with the *right* to spend that output, even after the timeout branch
> becomes another possible way to spend it.
>
> > LN commitment transactions have offered HTLC outputs where a counterparty
> > Alice is pledging to her other counterparty Caroll the HTLC amount in
> > exchange of a preimage (and Caroll signature).
> >
> > After the expiration of the HTLC timelock, if the HTLC has not been claimed
> > on-chain by Caroll, Alice can claim it back with her signature (and the
> > pre-exchanged Caroll signature).
> >
> > The exploit works actually in Caroll leveraging her HTLC-preimage
> > transaction as a replace-by-fee of Alice's HTLC-timeout _after_ the
> > expiration of the timelock, the HTLC-preimage transaction staying consensus
> > valid.
>
> That's precisely my point re: you not properly explaining the problem. If
> Caroll has the HTLC-preimage, she has the right to spend it. You need to
> explain why her right to spend that HTLC-preimage output should expire.
>
> If anything, the way you've explained it sounds like Bob has stolen the output
> from Caroll by virtue of the fact that Caroll wasn't able to spend the
> HTLC-preimage output in time.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev