1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7E349C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 17 Oct 2023 10:34:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 591E040324
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 17 Oct 2023 10:34:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 591E040324
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=p12tI8WR
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H4=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id yiZP4LHdHqyt
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 17 Oct 2023 10:34:17 +0000 (UTC)
Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch
[185.70.40.140])
by smtp4.osuosl.org (Postfix) with ESMTPS id E4F6940318
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 17 Oct 2023 10:34:16 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E4F6940318
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1697538854; x=1697798054;
bh=ctNxKHuNcqr6CjHGUiIJV/OGIDDpcaTiSZ0awKVk8/w=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=p12tI8WRVY/uqPdwz0qXlqXrkIAGP8UXfIVO1pGy13P5LDY+HtNY1Q+dArevgyjHG
upPQ8yz/1cFyVltxR10CoRBegj79QNg3hz8zwxt9AnCkt6FKm/EzHxIuSpfJdYNyv0
N0TgVVaOeB7r06B55W0vMwzH3ao33hSHjTQxJTjN3uM9bQb0TrdwyL4Fh4kQAeeRL/
kyV/X+tf2qfmcFQHAjHyNmuwgQhqkPRuqHTf1fvsewRGpKQhoJxIAzglaVPboZqRHw
KBSvJ0v2MBgajiwuGb7nIsA5CcuveR2DJy68HmHTEx6d27gCdm0fPi+z43gTf2FxX/
oVLVIz3rnCAqw==
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"
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Oct 2023 10:34:18 -0000
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
|
