MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <eW4O0HQJ2cbrzZhXSlgeDRWuhgRHXcAxIQCHJiqPh1zUxr270xPvl_tb7C4DUauZy56HaCq6BqGN9p4k-bkqQmLb4EHzPgIxZIZGVPlqyF0=@protonmail.com>
 <64VpLnXQLbeoc895Z9aR7C1CfH6IFxPFDrk0om-md1eqvdMczLSnhwH29T6EWCXgiGQiRqQnAYsezbvNvoPCdcfvCvp__Y8BA1ow5UwY2yQ=@protonmail.com>
In-Reply-To: <64VpLnXQLbeoc895Z9aR7C1CfH6IFxPFDrk0om-md1eqvdMczLSnhwH29T6EWCXgiGQiRqQnAYsezbvNvoPCdcfvCvp__Y8BA1ow5UwY2yQ=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 17 Oct 2023 19:34:52 +0100
Message-ID: <CALZpt+Gu9JJUeJfdUm_eT66DEH=UY+z1vkD_jUNZZyTPaet_QA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000ef8adb0607edc7c2"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 security@ariard.me,
 "lightning-dev\\\\\\\\\\\\\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 /
 CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are
 belong to us"
Precedence: list

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

Hi Zeeman,

> At block height 100, `B` notices the `B->C` HTLC timelock is expired
without `C` having claimed it, so `B` forces the `B=3D=3D=3D=3DC` channel o=
nchain.
> However, onchain feerates have risen and the commitment transaction and
HTLC-timeout transaction do not confirm.

This is not that the HTLC-timeout does not confirm. It is replaced in
cycles by C's HTLC-preimage which is still valid after `B->C` HTLC timelock
has expired. And this HTLC-preimage is subsequently replaced itself.

See the test here:
https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72=
f1efcf

> At block height 144, `B` is still not able to claim the `A->B` HTLC, so
`A` drops the `A=3D=3D=3D=3DB` channel onchain.
> As the fees are up-to-date, this confirms immediately and `A` is able to
recover the HTLC funds.
> However, the feerates of the `B=3D=3D=3D=3DC` pre-signed transactions rem=
ain at
the old, uncompetitive feerates.

This is correct that A tries to recover the HTLC funds on the `A=3D=3D=3DB`
channel.

However, there is no need to consider the fee rates nor mempool congestion
as the exploit lays on the replacement mechanism itself (in simple
scenario).

> At this point, `C` broadcasts an HTLC-success transaction with high
feerates that CPFPs the commitment tx.
> However, it replaces the HTLC-timeout transaction, which is at the old,
low feerate.
> `C` is thus able to get the value of the HTLC, but `B` is now no longer
able to use the knowledge of the preimage, as its own incoming HTLC was
already confirmed as claimed by `A`.

This is correct that `C` broadcasts an HTLC-success transaction at block
height 144.

However `C` broadcasts this high feerate transaction at _every block_
between blocks 100 and 144 to replace B's HTLC-timeout transaction.

> Let me also explain to non-Lightning experts why HTLC-timeout is
presigned in this case and why `B` cannot feebump it.

Note `B` can feebump the HTLC-timeout for anchor output channels thanks to
sighash_single | anyonecanpay on C's signature.

Le mar. 17 oct. 2023 =C3=A0 11:34, ZmnSCPxj <ZmnSCPxj@protonmail.com> a =C3=
=A9crit :

> Good morning Antoine et al.,
>
> Let me try to rephrase the core of the attack.
>
> There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes,
> `=3D=3D` are channels):
>
>     A =3D=3D=3D=3D=3D B =3D=3D=3D=3D=3D C
>
> `A` routes `A->B->C`.
>
> The timelocks, for example, could be:
>
>    A->B timeelock =3D 144
>    B->C timelock =3D 100
>
> The above satisfies the LN BOLT requirements, as long as `B` has a
> `cltv_expiry_delta` of 44 or lower.
>
> After `B` forwards the HTLC `B->C`, C suddenly goes offline, and all the
> signed transactions --- commitment transaction and HTLC-timeout
> transactions --- are "stuck" at the feerate at the time.
>
> At block height 100, `B` notices the `B->C` HTLC timelock is expired
> without `C` having claimed it, so `B` forces the `B=3D=3D=3D=3DC` channel=
 onchain.
> However, onchain feerates have risen and the commitment transaction and
> HTLC-timeout transaction do not confirm.
>
> In the mean time, `A` is still online with `B` and updates the onchain
> fees of the `A=3D=3D=3D=3DB` channel pre-signed transactions (commitment =
tx and
> HTLC-timeout tx) to the latest.
>
> At block height 144, `B` is still not able to claim the `A->B` HTLC, so
> `A` drops the `A=3D=3D=3D=3DB` channel onchain.
> As the fees are up-to-date, this confirms immediately and `A` is able to
> recover the HTLC funds.
> However, the feerates of the `B=3D=3D=3D=3DC` pre-signed transactions rem=
ain at
> the old, uncompetitive feerates.
>
> At this point, `C` broadcasts an HTLC-success transaction with high
> feerates that CPFPs the commitment tx.
> However, it replaces the HTLC-timeout transaction, which is at the old,
> low feerate.
> `C` is thus able to get the value of the HTLC, but `B` is now no longer
> able to use the knowledge of the preimage, as its own incoming HTLC was
> already confirmed as claimed by `A`.
>
> Is the above restatement accurate?
>
> ----
>
> Let me also explain to non-Lightning experts why HTLC-timeout is presigne=
d
> in this case and why `B` cannot feebump it.
>
> In the Poon-Dryja mechanism, the HTLCs are "infected" by the Poon-Dryja
> penalty case, and are not plain HTLCs.
>
> A plain HTLC offerred by `B` to `C` would look like this:
>
>     (B && OP_CLTV) || (C && OP_HASH160)
>
> However, on the commitment transaction held by `B`, it would be infected
> by the penalty case in this way:
>
>     (B && C && OP_CLTV) || (C && OP_HASH160) || (C && revocation)
>
> There are two changes:
>
> * The addition of a revocation branch `C && revocation`.
> * The branch claimable by `B` in the "plain" HTLC (`B && OP_CLTV`) also
> includes `C`.
>
> These are necessary in case `B` tries to cheat and this HTLC is on an old=
,
> revoked transaction.
> If the revoked transaction is *really* old, the `OP_CLTV` would already
> impose a timelock far in the past.
> This means that a plain `B && OP_CLTV` branch can be claimed by `B` if it
> retained this very old revoked transaction.
>
> To prevent that, `C` is added to the `B && OP_CLTV` branch.
> We also introduce an HTLC-timeout transaction, which spends the `B && C &=
&
> OP_CLTV` branch, and outputs to:
>
>     (B && OP_CSV) || (C && revocation)
>
> Thus, even if `B` held onto a very old revoked commitment transaction and
> attempts to spend the timelock branch (because the `OP_CLTV` is for an ol=
d
> blockheight), it still has to contend with a new output with a *relative*
> timelock.
>
> Unfortunately, this means that the HTLC-timeout transaction is pre-signed=
,
> and has a specific feerate.
> In order to change the feerate, both `B` and `C` have to agree to re-sign
> the HTLC-timeout transaction at the higher feerate.
>
> However, the HTLC-success transaction in this case spends the plain `(C &=
&
> OP_HASH160)` branch, which only involves `C`.
> This allows `C` to feebump the HTLC-success transaction arbitrarily even
> if `B` does not cooperate.
>
> While anchor outputs can be added to the HTLC-timeout transaction as well=
,
> `C` has a greater advantage here due to being able to RBF the HTLC-timeou=
t
> out of the way (1 transaction), while `B` has to get both HTLC-timeout an=
d
> a CPFP-RBF of the anchor output of the HTLC-timeout transaction (2
> transactions).
> `C` thus requires a smaller fee to achieve a particular feerate due to
> having to push a smaller number of bytes compared to `B`.
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr">Hi Zeeman,<div><br></div><div>&gt; At block height 100, `B=
` notices the `B-&gt;C` HTLC timelock is expired without `C` having claimed=
 it, so `B` forces the `B=3D=3D=3D=3DC` channel onchain.<br>&gt; However, o=
nchain feerates have risen and the commitment transaction and HTLC-timeout =
transaction do not confirm.<br></div><div><br></div><div>This is not that t=
he HTLC-timeout does not confirm. It is replaced in cycles by C&#39;s HTLC-=
preimage which is still valid after `B-&gt;C` HTLC timelock has expired. An=
d this HTLC-preimage is subsequently=C2=A0replaced itself.</div><div><br></=
div><div>See the test here:=C2=A0<a href=3D"https://github.com/ariard/bitco=
in/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf">https://github.com/aria=
rd/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf</a></div><div><b=
r></div><div>&gt; At block height 144, `B` is still not able to claim the `=
A-&gt;B` HTLC, so `A` drops the `A=3D=3D=3D=3DB` channel onchain.<br>&gt; A=
s the fees are up-to-date, this confirms immediately and `A` is able to rec=
over the HTLC funds.<br>&gt; However, the feerates of the `B=3D=3D=3D=3DC` =
pre-signed transactions remain at the old, uncompetitive feerates.<br></div=
><div><br></div><div>This is correct that A tries to recover the HTLC funds=
 on the `A=3D=3D=3DB` channel.</div><div><br></div><div>However, there is n=
o need to consider the fee rates nor mempool congestion as the exploit lays=
 on the replacement mechanism itself (in simple scenario).</div><div><br></=
div><div>&gt; At this point, `C` broadcasts an HTLC-success transaction wit=
h high feerates that CPFPs the commitment tx.</div>&gt; However, it replace=
s the HTLC-timeout transaction, which is at the old, low feerate.<br>&gt; `=
C` is thus able to get the value of the HTLC, but `B` is now no longer able=
 to use the knowledge of the preimage, as its own incoming HTLC was already=
 confirmed as claimed by `A`.<div><br></div><div>This is correct that `C` b=
roadcasts an HTLC-success transaction at block height 144.</div><div><br></=
div><div>However `C` broadcasts this high feerate transaction at _every blo=
ck_ between blocks 100 and 144 to replace B&#39;s HTLC-timeout transaction.=
</div><div><br></div><div>&gt; Let me also explain to non-Lightning experts=
 why HTLC-timeout is presigned in this case and why `B` cannot feebump it.<=
/div><div><br></div><div>Note `B` can feebump the HTLC-timeout for anchor o=
utput channels thanks to sighash_single |=C2=A0anyonecanpay=C2=A0on C&#39;s=
 signature.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">Le=C2=A0mar. 17 oct. 2023 =C3=A0=C2=A011:34, ZmnSCPxj &lt;=
<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; =
a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-=
left-color:rgb(204,204,204);padding-left:1ex">Good morning Antoine et al.,<=
br>
<br>
Let me try to rephrase the core of the attack.<br>
<br>
There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes, `=
=3D=3D` are channels):<br>
<br>
=C2=A0 =C2=A0 A =3D=3D=3D=3D=3D B =3D=3D=3D=3D=3D C<br>
<br>
`A` routes `A-&gt;B-&gt;C`.<br>
<br>
The timelocks, for example, could be:<br>
<br>
=C2=A0 =C2=A0A-&gt;B timeelock =3D 144<br>
=C2=A0 =C2=A0B-&gt;C timelock =3D 100<br>
<br>
The above satisfies the LN BOLT requirements, as long as `B` has a `cltv_ex=
piry_delta` of 44 or lower.<br>
<br>
After `B` forwards the HTLC `B-&gt;C`, C suddenly goes offline, and all the=
 signed transactions --- commitment transaction and HTLC-timeout transactio=
ns --- are &quot;stuck&quot; at the feerate at the time.<br>
<br>
At block height 100, `B` notices the `B-&gt;C` HTLC timelock is expired wit=
hout `C` having claimed it, so `B` forces the `B=3D=3D=3D=3DC` channel onch=
ain.<br>
However, onchain feerates have risen and the commitment transaction and HTL=
C-timeout transaction do not confirm.<br>
<br>
In the mean time, `A` is still online with `B` and updates the onchain fees=
 of the `A=3D=3D=3D=3DB` channel pre-signed transactions (commitment tx and=
 HTLC-timeout tx) to the latest.<br>
<br>
At block height 144, `B` is still not able to claim the `A-&gt;B` HTLC, so =
`A` drops the `A=3D=3D=3D=3DB` channel onchain.<br>
As the fees are up-to-date, this confirms immediately and `A` is able to re=
cover the HTLC funds.<br>
However, the feerates of the `B=3D=3D=3D=3DC` pre-signed transactions remai=
n at the old, uncompetitive feerates.<br>
<br>
At this point, `C` broadcasts an HTLC-success transaction with high feerate=
s that CPFPs the commitment tx.<br>
However, it replaces the HTLC-timeout transaction, which is at the old, low=
 feerate.<br>
`C` is thus able to get the value of the HTLC, but `B` is now no longer abl=
e to use the knowledge of the preimage, as its own incoming HTLC was alread=
y confirmed as claimed by `A`.<br>
<br>
Is the above restatement accurate?<br>
<br>
----<br>
<br>
Let me also explain to non-Lightning experts why HTLC-timeout is presigned =
in this case and why `B` cannot feebump it.<br>
<br>
In the Poon-Dryja mechanism, the HTLCs are &quot;infected&quot; by the Poon=
-Dryja penalty case, and are not plain HTLCs.<br>
<br>
A plain HTLC offerred by `B` to `C` would look like this:<br>
<br>
=C2=A0 =C2=A0 (B &amp;&amp; OP_CLTV) || (C &amp;&amp; OP_HASH160)<br>
<br>
However, on the commitment transaction held by `B`, it would be infected by=
 the penalty case in this way:<br>
<br>
=C2=A0 =C2=A0 (B &amp;&amp; C &amp;&amp; OP_CLTV) || (C &amp;&amp; OP_HASH1=
60) || (C &amp;&amp; revocation)<br>
<br>
There are two changes:<br>
<br>
* The addition of a revocation branch `C &amp;&amp; revocation`.<br>
* The branch claimable by `B` in the &quot;plain&quot; HTLC (`B &amp;&amp; =
OP_CLTV`) also includes `C`.<br>
<br>
These are necessary in case `B` tries to cheat and this HTLC is on an old, =
revoked transaction.<br>
If the revoked transaction is *really* old, the `OP_CLTV` would already imp=
ose a timelock far in the past.<br>
This means that a plain `B &amp;&amp; OP_CLTV` branch can be claimed by `B`=
 if it retained this very old revoked transaction.<br>
<br>
To prevent that, `C` is added to the `B &amp;&amp; OP_CLTV` branch.<br>
We also introduce an HTLC-timeout transaction, which spends the `B &amp;&am=
p; C &amp;&amp; OP_CLTV` branch, and outputs to:<br>
<br>
=C2=A0 =C2=A0 (B &amp;&amp; OP_CSV) || (C &amp;&amp; revocation)<br>
<br>
Thus, even if `B` held onto a very old revoked commitment transaction and a=
ttempts to spend the timelock branch (because the `OP_CLTV` is for an old b=
lockheight), it still has to contend with a new output with a *relative* ti=
melock.<br>
<br>
Unfortunately, this means that the HTLC-timeout transaction is pre-signed, =
and has a specific feerate.<br>
In order to change the feerate, both `B` and `C` have to agree to re-sign t=
he HTLC-timeout transaction at the higher feerate.<br>
<br>
However, the HTLC-success transaction in this case spends the plain `(C &am=
p;&amp; OP_HASH160)` branch, which only involves `C`.<br>
This allows `C` to feebump the HTLC-success transaction arbitrarily even if=
 `B` does not cooperate.<br>
<br>
While anchor outputs can be added to the HTLC-timeout transaction as well, =
`C` has a greater advantage here due to being able to RBF the HTLC-timeout =
out of the way (1 transaction), while `B` has to get both HTLC-timeout and =
a CPFP-RBF of the anchor output of the HTLC-timeout transaction (2 transact=
ions).<br>
`C` thus requires a smaller fee to achieve a particular feerate due to havi=
ng to push a smaller number of bytes compared to `B`.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000ef8adb0607edc7c2--