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
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
|
Return-Path: <antoine.riard@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id B37C6C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 17 Oct 2023 01:11:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 7C9ED4191D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 17 Oct 2023 01:11:34 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7C9ED4191D
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20230601 header.b=FpxtUFKM
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 xtdCSXtoYES5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 17 Oct 2023 01:11:33 +0000 (UTC)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com
[IPv6:2607:f8b0:4864:20::130])
by smtp4.osuosl.org (Postfix) with ESMTPS id 07F3C4190B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 17 Oct 2023 01:11:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 07F3C4190B
Received: by mail-il1-x130.google.com with SMTP id
e9e14a558f8ab-35749078a59so21075235ab.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 16 Oct 2023 18:11:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1697505092; x=1698109892;
darn=lists.linuxfoundation.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=XGcQGN9+57vWq9FdjR0rPBuZJ3vIto8mMQt5AlrWm3k=;
b=FpxtUFKMvT5mDUApyVPJyUf8s9c+xDTexON9TBk2D6xz8wduyyNYbzxU8+HhqFUz2L
nT5o6tlAE8hH2A5DEJGmMHolmoh8r9TQL+s5fZBd8YgQlWukA+Gu50NRg2qxHp+T3Avv
XfaudAhIlRDTmV1yoLXDDAOUcfvGQ5TBomtUCfhBb8Rz0v6smyiOcTGGL+SSESk9jIgt
kx+kSK943/3c2AKF+7j0N1JhJ+D60CFag6f5RnbivIBHP/G6MN6kKu/nqz0qdALKepUa
HywbS9n8p6Fqrx4kYYIf3SSZQWKsA/c2K780Rdfi6QAFNC6aszWs5GqAIBHqk91vsZot
zxzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1697505092; x=1698109892;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=XGcQGN9+57vWq9FdjR0rPBuZJ3vIto8mMQt5AlrWm3k=;
b=HZ0BZh70/tcN0EekjeGw1oYIr2MYmw/cYn/fqEcyBiBnne2RS/3ZBRkQsViTKsf35y
G7DxeofUZfZ6PzVjHY59qycD/v1ArIAhpx+ZEQVMYw04kCF+C4Y80XGD6CR1yFscpZ9Q
8Q+mROqxYa0fTTVXFswGlsDnlqfFgwyUjcFbdccSvCUGXRexyM7zaEZN+IpvnWu86o8Z
9M8RWnn0P3oegYM4OY+3SXeXbdRey4wwz3vd19PousyVOoLP4vnhfUkSpNxkWvAaVB3c
y5JUFPqEF4rgEKzDkiubjZ0osrBIqvArfXkX1P9xiRupcki4+B2ZOa1It/EQ47KVf1nP
9/lg==
X-Gm-Message-State: AOJu0YxsjfouBBOCetLgbppp3htawsrwvdgufzZFR4XJdBXbDyEEUfpv
XYSPSc/bZkVz1f1N8wu8MpYP8dWvBKaMk5+fzxwLQ7MxlbuVpA==
X-Google-Smtp-Source: AGHT+IGg4u+qmZGchdcWtbfsSbE7Xq6opKwxSECF1ntnYqPiwEW0W2YwrBxRo5k4imBFK/hDMrt2SWqbQeseQqvzn7E=
X-Received: by 2002:a05:6e02:1d1a:b0:357:54d8:94f6 with SMTP id
i26-20020a056e021d1a00b0035754d894f6mr1321660ila.3.1697505091970; Mon, 16 Oct
2023 18:11:31 -0700 (PDT)
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"
X-Mailman-Approved-At: Tue, 17 Oct 2023 01:21:14 +0000
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"
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 01:11:34 -0000
--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">> 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'm correctly understanding your question, you'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'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's HTLC-pr=
eimage of being replaced subsequently, once Alice'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's ch=
annel expires, the "forward" 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 <<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</=
a>> 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 <=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
>(cross-posting mempool issues identified are exposing lightning chan to=
<br>
>loss of funds risks, other multi-party bitcoin apps might be affected)<=
br>
><br>
>As the HTLC-preimage spends an unconfirmed input that was already inclu=
ded<br>
>in the unconfirmed and unrelated child transaction (rule 2), pays an<br=
>
>absolute higher fee of at least the sum paid by the HTLC-timeout and ch=
ild<br>
>transaction (rule 3) and the HTLC-preimage feerate is greater than all<=
br>
>directly conflicting transactions (rule 6), the replacement is accepted=
.<br>
>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--
|