Date: Tue, 17 Oct 2023 10:34:04 +0000
To: "lightning-dev\\\\\\\\\\\\\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <64VpLnXQLbeoc895Z9aR7C1CfH6IFxPFDrk0om-md1eqvdMczLSnhwH29T6EWCXgiGQiRqQnAYsezbvNvoPCdcfvCvp__Y8BA1ow5UwY2yQ=@protonmail.com>
In-Reply-To: <eW4O0HQJ2cbrzZhXSlgeDRWuhgRHXcAxIQCHJiqPh1zUxr270xPvl_tb7C4DUauZy56HaCq6BqGN9p4k-bkqQmLb4EHzPgIxZIZGVPlqyF0=@protonmail.com>
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <eW4O0HQJ2cbrzZhXSlgeDRWuhgRHXcAxIQCHJiqPh1zUxr270xPvl_tb7C4DUauZy56HaCq6BqGN9p4k-bkqQmLb4EHzPgIxZIZGVPlqyF0=@protonmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: security@ariard.me
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

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_ex=
piry_delta` of 44 or lower.

After `B` forwards the HTLC `B->C`, C suddenly goes offline, and all the si=
gned 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 withou=
t `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 HTL=
C-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 re=
cover the HTLC funds.
However, the feerates of the `B=3D=3D=3D=3DC` pre-signed transactions remai=
n at the old, uncompetitive feerates.

At this point, `C` broadcasts an HTLC-success transaction with high feerate=
s 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 abl=
e to use the knowledge of the preimage, as its own incoming HTLC was alread=
y confirmed as claimed by `A`.

Is the above restatement accurate?

----

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

In the Poon-Dryja mechanism, the HTLCs are "infected" by the Poon-Dryja pen=
alty 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 inc=
ludes `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 imp=
ose a timelock far in the past.
This means that a plain `B && OP_CLTV` branch can be claimed by `B` if it r=
etained 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 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.

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 t=
he 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-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).
`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`.

Regards,
ZmnSCPxj