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
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
|
Delivery-date: Thu, 15 Aug 2024 21:47:31 -0700
Received: from mail-yb1-f191.google.com ([209.85.219.191])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBC3PT7FYWAMRBWVT7O2QMGQEB6AGY4Q@googlegroups.com>)
id 1seos6-000202-A3
for bitcoindev@gnusha.org; Thu, 15 Aug 2024 21:47:30 -0700
Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e1169005d9asf2865796276.0
for <bitcoindev@gnusha.org>; Thu, 15 Aug 2024 21:47:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1723783644; x=1724388444; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=81MLUyHghGvJCAs4WewTICMKmehHNcK8okBmwlIuxvI=;
b=bd1BsBOzI5/UgGvA4aiOUaySP2Granw7p+e4IvVjOFizhhhnLNKtwHJ5qnfXFQdOah
M+ls1OJl0G0mESUG0Hok150hGn4A6d5vIDTb0UAjsLrOWblwqUDHK9tgKiWf3msoFvnR
P+dntb3SrPflk6vG+LFUP32ZoAgOsNWKN3tg20bsrB+d5eJcpgMFBU+tC6NI+YGsZhaC
z6r0EvAIJC6F+vHKiv4v8sLPPveIc0Ws9QMs177VdR9oFa3UaCEZSUxssY1ql0iWdEtl
VUjMoFiZLKKRhd0RL/s2lv0Nu3usIFnzjzoRlzya3RAINgqi3gcw3AMoPQEb/YrHMtro
jqOA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1723783644; x=1724388444; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:from:to:cc
:subject:date:message-id:reply-to;
bh=81MLUyHghGvJCAs4WewTICMKmehHNcK8okBmwlIuxvI=;
b=HQPS3vJrZryjYF2LbVXIQvFmlfQW8sWVcs2w64RoYEhyR1HqHiKo7MMMKc/AJBilkp
X+ixQt1hQ4jN3jDbeGYXrKCWa/PknKgOppYxogUu4PBOTVMY5wSDiN7/HIpiL+kgvKBb
CgU1MC+bjEBEer6GJtJ+yamS4LzhVgRfmu/gHQA8aaf/XQF3ZF4taGo4FQyRK/iuK8by
Z3uwrIQvxyOkFR7tvWx3PLHT2hTz3JpqHbLv1tPPvK0atmK77yLE+sLY/ivCWAyy3PsU
CjGfxApcYDHOYqDdez8QBbeE4M08kpXCeZ9S6uDUlMPJqbpOVNP3n/9zo/FsA7NChGRq
XqQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1723783644; x=1724388444;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=81MLUyHghGvJCAs4WewTICMKmehHNcK8okBmwlIuxvI=;
b=txo+qtQqWV68hJPeTR8koTJP4GXrjCjsQs1+s848Nslcc2lXJGIRrn/CmL0DrpyD8w
C4ZfV8Q4phLyiE/ckANKnx0yWhFoK1SLPoJY3ng87vpsI3Iop+hZ3ylVLgpFQgbPAcP1
7+jGa4Wbqpj0AtPU62kXClOndEYXivlZmVwpVjYb9YDCXXl5XcEoaJxJrRDZO7Xr/Wy0
QUox9oDiV9usQ4UGUxUtT/pnS2sv+zH0oKD9H1Vt6YKBQC8m9lM6xuGshzSkhpZgAq5G
pJ2fNUmGF1x2z9v2otxOYeUQcnEzgGXcUZ+SOMNKrE7SMzq+LwPCVNEa9lq+nfptEKaf
iD/A==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVFbZK38bfWlsK038JaIuMf2QCgGvID0fjQbbHsbdhSLFCcbARooUo8P7FdW/ymHTUDHnyiQOJNqlW9ifGOmYhUwYa+aCE=
X-Gm-Message-State: AOJu0YwX12vUbDj1coIA+6m8pfCgdXiVoznJfU0a1Cuz1pLuKQqnGmg8
/O0Y3WQ7WwOIHRKo50Qf2ZLFgV19oHHzMkcTBLl37Q6tv2Fphxif
X-Google-Smtp-Source: AGHT+IGNpOCSG04nJo5Qk0WFjkjjm+4I5ImnaM2FcHVy2BSKwnO9+nN4G2u5yEuTKTWO90h3UzweDQ==
X-Received: by 2002:a05:6902:723:b0:e11:5d18:2ade with SMTP id 3f1490d57ef6-e1180ef8200mr2536602276.29.1723783643731;
Thu, 15 Aug 2024 21:47:23 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:18cd:b0:e0b:3363:5986 with SMTP id
3f1490d57ef6-e116beadad1ls56951276.1.-pod-prod-08-us; Thu, 15 Aug 2024
21:47:22 -0700 (PDT)
X-Received: by 2002:a25:9708:0:b0:e0e:a784:2957 with SMTP id 3f1490d57ef6-e1180e55b80mr10309276.1.1723783642525;
Thu, 15 Aug 2024 21:47:22 -0700 (PDT)
Received: by 2002:a05:690c:f0d:b0:627:7f59:2eee with SMTP id 00721157ae682-6ad370aa13dms7b3;
Thu, 15 Aug 2024 21:45:17 -0700 (PDT)
X-Received: by 2002:a25:ef4b:0:b0:e11:5da7:337 with SMTP id 3f1490d57ef6-e1180e5b5b8mr12654276.3.1723783516911;
Thu, 15 Aug 2024 21:45:16 -0700 (PDT)
Date: Thu, 15 Aug 2024 21:45:16 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <04a22956-b722-4f6c-b8d5-0f8905359721n@googlegroups.com>
In-Reply-To: <ZqlBKVXBKKIurBPk@petertodd.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
<c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
<99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com>
<4e959cdbe70b1a3b9f1adb37fe3b986e@dtrt.org>
<ZqlBKVXBKKIurBPk@petertodd.org>
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack
of Full-RBF In Core
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_27274_1705358906.1723783516668"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)
------=_Part_27274_1705358906.1723783516668
Content-Type: multipart/alternative;
boundary="----=_Part_27275_343673669.1723783516668"
------=_Part_27275_343673669.1723783516668
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Peter,
> It is not.
>=20
> I've actually *accidentally* exploited this type of pinning vector a few=
=20
times
> in Lighting channels by simply force closing them at times when fee-rates=
=20
were
> high. I've even twice managed to delay the force close of a channel by=20
testing
> out justice transactions by broadcasting a low fee-rate, revoked=20
commitment,
> which the counterparty node did not notice. Instead, the channel just=20
stayed
> in limbo for a few days until the node finally got in a normal force-clos=
e
> using the non-revoked state after fees reduced. In both cases, both=20
endpoints
> were LND using compact block filters (I was running both nodes in these=
=20
tests).
> IIUC the LND compat block filter implementation does not track mempool
> transactions, so it only notices revoked commitment transactions when the=
y
> appear in blocks (notice how this means that the lack of package relay=20
will
> render LND's fee-bumping code potentially useless if the conflicting=20
commitment
> transaction is equal or greater fee/fee-rate).
>=20
> I haven't tried fully exploiting this particular scenario by maximizing=
=20
the
> number of HTLCs in flight; I was just trying out stuff manually. Someone
> should.
>=20
> It should be relatively easy to automate this class type of attack by=20
simply
> picking opportunities for it based on fee rates. It's quite common for fe=
e
> spikes to cause conditions where you can easily predict that fees won't g=
o
> below certain levels for many blocks in the future, multiple days even.=
=20
Your
> claim that "estimating feerates correctly for over 144 blocks in a row=20
sounds
> difficult" is very wrong.
After reading Dave description of the "loophole pinning" attack, which is a
re-formalization of my gitub comment on one of the TRUC PR, I'm not entirel=
y
sure, we're describing the same exploitation scenario. Finely evaluating th=
e
viability of an attack, before the attack scheme and attacker capabilities=
=20
are
fleshed out is a bit premature...
Especially, when you're saying few more lines after that you have tried to
fully exploit this scenario with HTLCs in flights, and all other attempts
were more accidental and without being sure the LND software correctly
implements RBF, including the rule 5 penalty computation at all time (you'r=
e
observing yourself the limitations of LND's fee-bumping code).
If there is a lightning node on mainnet of yours that your formally=20
authorize
me to test some pinning attacks, I could try a demo. Alternatively, I can
setup a LN node + full-node on some long-running infrastructure, if you wis=
h
to try the scenario on your side. Though, as observed by Dave there is no
lightning code written yet to opt-in into TRUC transactions.
On the last observation, I agree with you that is a class type of attack=20
that
one could automate by leveraging fee-estimation algorithms.
Best,
Antoine
ots hash: a958c5bf1a5af3f3fd2b3788b201b95707621cfecc9b1478075a0da4d8c5c0a5
Le mardi 30 juillet 2024 =C3=A0 20:58:08 UTC+1, Peter Todd a =C3=A9crit :
> On Mon, Jul 29, 2024 at 06:57:17PM -1000, David A. Harding wrote:
> > Given the first point and the last point, I'm not sure how viable the
> > attack is (but, as I said, I'm not sure I understand it). Estimating or
> > manipulating feerates correctly for over 144 blocks in a row sounds
> > difficult. Counterparties being able to deprive Mallory of profit seems
> > like a major weakness.
>
> It is not.
>
> I've actually *accidentally* exploited this type of pinning vector a few=
=20
> times
> in Lighting channels by simply force closing them at times when fee-rates=
=20
> were
> high. I've even twice managed to delay the force close of a channel by=20
> testing
> out justice transactions by broadcasting a low fee-rate, revoked=20
> commitment,
> which the counterparty node did not notice. Instead, the channel just=20
> stayed
> in limbo for a few days until the node finally got in a normal force-clos=
e
> using the non-revoked state after fees reduced. In both cases, both=20
> endpoints
> were LND using compact block filters (I was running both nodes in these=
=20
> tests).
> IIUC the LND compat block filter implementation does not track mempool
> transactions, so it only notices revoked commitment transactions when the=
y
> appear in blocks (notice how this means that the lack of package relay wi=
ll
> render LND's fee-bumping code potentially useless if the conflicting=20
> commitment
> transaction is equal or greater fee/fee-rate).
>
> I haven't tried fully exploiting this particular scenario by maximizing t=
he
> number of HTLCs in flight; I was just trying out stuff manually. Someone
> should.
>
> It should be relatively easy to automate this class type of attack by=20
> simply
> picking opportunities for it based on fee rates. It's quite common for fe=
e
> spikes to cause conditions where you can easily predict that fees won't g=
o
> below certain levels for many blocks in the future, multiple days even.=
=20
> Your
> claim that "estimating feerates correctly for over 144 blocks in a row=20
> sounds
> difficult" is very wrong.
>
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/04a22956-b722-4f6c-b8d5-0f8905359721n%40googlegroups.com.
------=_Part_27275_343673669.1723783516668
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Peter,<br /><br />> It is not.<br />> <br />> I've actually *ac=
cidentally* exploited this type of pinning vector a few times<br />> in =
Lighting channels by simply force closing them at times when fee-rates were=
<br />> high. I've even twice managed to delay the force close of a chan=
nel by testing<br />> out justice transactions by broadcasting a low fee=
-rate, revoked commitment,<br />> which the counterparty node did not no=
tice. Instead, the channel just stayed<br />> in limbo for a few days un=
til the node finally got in a normal force-close<br />> using the non-re=
voked state after fees reduced. In both cases, both endpoints<br />> wer=
e LND using compact block filters (I was running both nodes in these tests)=
.<br />> IIUC the LND compat block filter implementation does not track =
mempool<br />> transactions, so it only notices revoked commitment trans=
actions when they<br />> appear in blocks (notice how this means that th=
e lack of package relay will<br />> render LND's fee-bumping code potent=
ially useless if the conflicting commitment<br />> transaction is equal =
or greater fee/fee-rate).<br />> <br />> I haven't tried fully exploi=
ting this particular scenario by maximizing the<br />> number of HTLCs i=
n flight; I was just trying out stuff manually. Someone<br />> should.<b=
r />> <br />> It should be relatively easy to automate this class typ=
e of attack by simply<br />> picking opportunities for it based on fee r=
ates. It's quite common for fee<br />> spikes to cause conditions where =
you can easily predict that fees won't go<br />> below certain levels fo=
r many blocks in the future, multiple days even. Your<br />> claim that =
"estimating feerates correctly for over 144 blocks in a row sounds<br />>=
; difficult" is very wrong.<br /><br />After reading Dave description of th=
e "loophole pinning" attack, which is a<br />re-formalization of my gitub c=
omment on one of the TRUC PR, I'm not entirely<br />sure, we're describing =
the same exploitation scenario. Finely evaluating the<br />viability of an =
attack, before the attack scheme and attacker capabilities are<br />fleshed=
out is a bit premature...<br /><br />Especially, when you're saying few mo=
re lines after that you have tried to<br />fully exploit this scenario with=
HTLCs in flights, and all other attempts<br />were more accidental and wit=
hout being sure the LND software correctly<br />implements RBF, including t=
he rule 5 penalty computation at all time (you're<br />observing yourself t=
he limitations of LND's fee-bumping code).<br /><br />If there is a lightni=
ng node on mainnet of yours that your formally authorize<br />me to test so=
me pinning attacks, I could try a demo. Alternatively, I can<br />setup a L=
N node + full-node on some long-running infrastructure, if you wish<br />to=
try the scenario on your side. Though, as observed by Dave there is no<br =
/>lightning code written yet to opt-in into TRUC transactions.<br /><br />O=
n the last observation, I agree with you that is a class type of attack tha=
t<br />one could automate by leveraging fee-estimation algorithms.<br /><br=
/>Best,<br />Antoine<br />ots hash: a958c5bf1a5af3f3fd2b3788b201b95707621c=
fecc9b1478075a0da4d8c5c0a5<br /><br /><div class=3D"gmail_quote"><div dir=
=3D"auto" class=3D"gmail_attr">Le mardi 30 juillet 2024 =C3=A0 20:58:08 UTC=
+1, Peter Todd a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204)=
; padding-left: 1ex;">On Mon, Jul 29, 2024 at 06:57:17PM -1000, David A. Ha=
rding wrote:
<br>> Given the first point and the last point, I'm not sure how via=
ble the
<br>> attack is (but, as I said, I'm not sure I understand it). Est=
imating or
<br>> manipulating feerates correctly for over 144 blocks in a row sound=
s
<br>> difficult. Counterparties being able to deprive Mallory of profit=
seems
<br>> like a major weakness.
<br>
<br>It is not.
<br>
<br>I've actually *accidentally* exploited this type of pinning vector =
a few times
<br>in Lighting channels by simply force closing them at times when fee-rat=
es were
<br>high. I've even twice managed to delay the force close of a channel=
by testing
<br>out justice transactions by broadcasting a low fee-rate, revoked commit=
ment,
<br>which the counterparty node did not notice. Instead, the channel just =
stayed
<br>in limbo for a few days until the node finally got in a normal force-cl=
ose
<br>using the non-revoked state after fees reduced. In both cases, both end=
points
<br>were LND using compact block filters (I was running both nodes in these=
tests).
<br>IIUC the LND compat block filter implementation does not track mempool
<br>transactions, so it only notices revoked commitment transactions when t=
hey
<br>appear in blocks (notice how this means that the lack of package relay =
will
<br>render LND's fee-bumping code potentially useless if the conflictin=
g commitment
<br>transaction is equal or greater fee/fee-rate).
<br>
<br>I haven't tried fully exploiting this particular scenario by maximi=
zing the
<br>number of HTLCs in flight; I was just trying out stuff manually. Someon=
e
<br>should.
<br>
<br>It should be relatively easy to automate this class type of attack by s=
imply
<br>picking opportunities for it based on fee rates. It's quite common =
for fee
<br>spikes to cause conditions where you can easily predict that fees won&#=
39;t go
<br>below certain levels for many blocks in the future, multiple days even.=
Your
<br>claim that "estimating feerates correctly for over 144 blocks in a=
row sounds
<br>difficult" is very wrong.
<br>
<br>--=20
<br><a href=3D"https://petertodd.org" target=3D"_blank" rel=3D"nofollow" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttps://pe=
tertodd.org&source=3Dgmail&ust=3D1723869845122000&usg=3DAOvVaw0=
Bw-iSvzWNJwUgsyoRzhoI">https://petertodd.org</a> 'peter'[:-1]@<a hr=
ef=3D"http://petertodd.org" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Dfr&q=3Dhttp://petertodd.org=
&source=3Dgmail&ust=3D1723869845122000&usg=3DAOvVaw2f00vpl6Qan8=
aIXE9rwFCY">petertodd.org</a>
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/04a22956-b722-4f6c-b8d5-0f8905359721n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/04a22956-b722-4f6c-b8d5-0f8905359721n%40googlegroups.com</a>.=
<br />
------=_Part_27275_343673669.1723783516668--
------=_Part_27274_1705358906.1723783516668--
|