MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <7ED2BCD8-BAE3-48E3-9749-A396F3724B6E@petertodd.org>
In-Reply-To: <7ED2BCD8-BAE3-48E3-9749-A396F3724B6E@petertodd.org>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 17 Oct 2023 02:11:20 +0100
Message-ID: <CALZpt+GsRfHvABjhkX=eN_1viVw8Jos4=+sBd7vWQJ_VxNta8g@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="00000000000002eae50607df349f"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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

--00000000000002eae50607df349f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> 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.

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.

There is nothing in the mempool policy rules that prevent this Caroll's
HTLC-preimage of being replaced subsequently, once Alice's HTLC-timeout has
been evicted out the mempool.

The HTLC output does not have any spend candidate remaining for this block.
If this replacement can be successfully repeated until an inbound HTLC on
another Alice's channel expires, the "forward" HTLC can be double-spent.


Le lun. 16 oct. 2023 =C3=A0 20:13, Peter Todd <pete@petertodd.org> a =C3=A9=
crit :

>
>
> On October 16, 2023 6:57:36 PM GMT+02:00, Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >(cross-posting mempool issues identified are exposing lightning chan to
> >loss of funds risks, other multi-party bitcoin apps might be affected)
> >
> >As the HTLC-preimage spends an unconfirmed input that was already includ=
ed
> >in the unconfirmed and unrelated child transaction (rule 2), pays an
> >absolute higher fee of at least the sum paid by the HTLC-timeout and chi=
ld
> >transaction (rule 3) and the HTLC-preimage feerate is greater than all
> >directly conflicting transactions (rule 6), the replacement is accepted.
> >The honest HTLC-timeout is evicted out of the mempool.
>
> I think if you want people to understand this exploit, you need to explai=
n
> 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.
>

--00000000000002eae50607df349f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; I think if you want people to understand this exploit=
, you need to explain in more detail how we have a situation where two diff=
erent parties can spend the same HTLC txout, without the first party having=
 the right to spend it via their knowledge of the HTLC-preimage.<br><div><b=
r></div><div>If I&#39;m correctly understanding your question, you&#39;re a=
sking why we have a situation where the spend of a HTLC output can be in co=
mpetition between 2 channel counterparties.</div><div><br></div><div>LN com=
mitment transactions have offered HTLC outputs where a counterparty Alice i=
s pledging to her other counterparty Caroll the HTLC amount in exchange of =
a preimage (and Caroll signature).</div><div><br></div><div>After the expir=
ation of the HTLC timelock, if the HTLC has not been claimed on-chain by Ca=
roll, Alice can claim it back with her signature=C2=A0(and the pre-exchange=
d Caroll signature).</div><div><br></div><div>The exploit works actually in=
 Caroll leveraging her HTLC-preimage transaction as a replace-by-fee of Ali=
ce&#39;s HTLC-timeout _after_ the expiration of the timelock, the HTLC-prei=
mage transaction staying consensus valid.</div><div><br></div><div>There is=
 nothing in the mempool policy rules that prevent this Caroll&#39;s HTLC-pr=
eimage of being replaced subsequently, once Alice&#39;s HTLC-timeout has be=
en evicted out the mempool.</div><div><br></div><div>The HTLC output does n=
ot have any spend candidate remaining for this block. If this replacement c=
an be successfully repeated until an inbound HTLC on another Alice&#39;s ch=
annel expires, the &quot;forward&quot; HTLC can be double-spent. =C2=A0</di=
v><div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">Le=C2=A0lun. 16 oct. 2023 =C3=A0=C2=A020:13=
, Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</=
a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><br>
<br>
On October 16, 2023 6:57:36 PM GMT+02:00, Antoine Riard via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;(cross-posting mempool issues identified are exposing lightning chan to=
<br>
&gt;loss of funds risks, other multi-party bitcoin apps might be affected)<=
br>
&gt;<br>
&gt;As the HTLC-preimage spends an unconfirmed input that was already inclu=
ded<br>
&gt;in the unconfirmed and unrelated child transaction (rule 2), pays an<br=
>
&gt;absolute higher fee of at least the sum paid by the HTLC-timeout and ch=
ild<br>
&gt;transaction (rule 3) and the HTLC-preimage feerate is greater than all<=
br>
&gt;directly conflicting transactions (rule 6), the replacement is accepted=
.<br>
&gt;The honest HTLC-timeout is evicted out of the mempool.<br>
<br>
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 spen=
d the same HTLC txout, without the first party having the right to spend it=
 via their knowledge of the HTLC-preimage.<br>
</blockquote></div>

--00000000000002eae50607df349f--