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
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
|
Delivery-date: Thu, 28 Mar 2024 12:29:32 -0700
Received: from mail-qt1-f189.google.com ([209.85.160.189])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBC3PT7FYWAMRBFEKS6YAMGQEXWM6V3Y@googlegroups.com>)
id 1rpvRL-0007yh-NO
for bitcoindev@gnusha.org; Thu, 28 Mar 2024 12:29:32 -0700
Received: by mail-qt1-f189.google.com with SMTP id d75a77b69052e-4317b440bcesf10930811cf.2
for <bitcoindev@gnusha.org>; Thu, 28 Mar 2024 12:29:31 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1711654165; cv=pass;
d=google.com; s=arc-20160816;
b=oDfCRaE+IsK0bgNk6rn0FL+v8ffMYx96+gZqabDDu9c/yeqo6P132ozOV+hauXwD7L
R6SmAKKX7ahOaFzK5JWTTw0bn3uXv+aT+9UphkcAIxkCOieYx30uuuGr5UgBmj87bQ8K
8hCLQWPl39zjrRkAQpGzv4Yjn1Om8maENKDE1VbmM+t86/RYjlLzYQxoqYmkwFtK8Bkj
nT+Maw7kXfq3dYlAgYV0b1CqrveawX3UNc7KXZby5YiPIDkGNq99xZ5x8ItCn8BIWO5J
seIgnKskuXsLPgJllLsoXdtDTlyJo0GaCljm9TcQii9e2DkKGJ+LsB2/5N2YBzzuTQLg
qs1Q==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:sender:dkim-signature
:dkim-signature;
bh=4rNueEZwHcqOp7cvfZQXfWlUccovAOrQQ2nZc0xtewA=;
fh=l9/B7RWad72s0SRfYu/aTBF5zIUdU4Z3uIp6AQC+M3g=;
b=FJoWoJB5IbyjK74Ogk+TKjFxA9SBlkYa5cYen+SonmaXsF7n6AQnDe+FjOjJiMY0y4
ZPKovFWjNsZQgqnhfWxTLSSIpyfTR8Us4ryZ+ao3FUY3dh+wATtv5n+IIABVwfUR47Im
6P4lcEFc5OJl5VMHi5rPkwBor0hpuDkqE/J3+ob2QlvHfcqOrGEdLbxtokuMnQLqnZGi
uwiycRHvvIMkHiuG0JewtTTx4E+6k7cV7kyhKaxha6p1orzZw05APbft6AKZxdf1pSr6
Vk3Tr8+8zU4TdUhoEtSOjJyB0sAqOcSIe7fkPVMzhaJDIv49MN/S3y2QiCWyTJEtBTgZ
PepA==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@gmail.com header.s=20230601 header.b=LeZC+T9y;
spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::d29 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com;
dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1711654165; x=1712258965; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
:references:mime-version:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=4rNueEZwHcqOp7cvfZQXfWlUccovAOrQQ2nZc0xtewA=;
b=MOWC/sAjxy6KoSHXRN78GKt+DkcvQpqAlMRiSj54/iARr4m4wsjjkqy6XqFDEAZ2jA
foxq1Irf5LYMGTz4FVYNlFMGwVc847/Wl7I8MAGZHPQORVXiaIsuY86H0DCF/fklloby
hoOi7jKIEDXzk3fQ/D2p7hsNg3rUrWy48ePFBxycvR3OXA32r1JLE1x+g7wBS1lYXMOd
I/BG+5hcKAiSinC2G4ZU8oexsUnMH7ZM/hEp2pA7gVRnKO62oD1D6nwIsfOo2oT67oY8
IFzV5V4t0k3qrb00o4+BK2ztbXKympKQdRN1HqZ+DjGN9EZMmexxbdBQ7kyVjT62kWXp
qftg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1711654165; x=1712258965; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
:references:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=4rNueEZwHcqOp7cvfZQXfWlUccovAOrQQ2nZc0xtewA=;
b=UJ8AB7o2XTO07aLwL1LFPeTY+9xBgcdG5mGMQlXUy6CKqS63+vg4BJd2EgaI/SY83w
SFreQbqYZIc7S5VW+WuiJ9eL+3usDvtcYnvdzlWwXEKna6PsvVLYzz5FYLVK5BjBeRE9
gJOAG0r8mbNpok5XLg8hXm3bJjsrJTedgFnzRAsbJNHOEs9Wxsip9Z3hrk7pqJ9dvpEN
oPava0/PZNyfh2N26Lk0OJ/OMe2H5sd8QpJ6+lxixZRWSurXAjyzgYqp9cyxG0GygVCQ
H2MISGEc7PZEcY0flf9v5vT2scdBL+j0QYpGPCyHKHfU8qW/YcDpnOkvhmVpARBuDaom
+z8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1711654165; x=1712258965;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
:references:mime-version:x-beenthere:x-gm-message-state:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=4rNueEZwHcqOp7cvfZQXfWlUccovAOrQQ2nZc0xtewA=;
b=bwNN1qqPPUHXzejGBA/YOwHlNNKTA+aH0Ui79cjuhFpNR1MbVpkcKTfP3ToP4no6rm
enH5sG/g7w84thJ8JyR4HDrxk6M6PeurIpktdnL1v3Mag0EC7p9Cds54N7ww3hfydApy
u+RzJjJcN6hnJink+XW89tb5WR0hK1n1jL+ejLzgmTVpKwcxYxNYlGd0tJnXyWCZjPM3
ZGCtlbTZKf3hgPsmbFwBzppS0BIRrJAqDWVy5dXq1KPO6Koq3+oEOhOz3I6FtMSXmUSp
uLH3MYh55N+5RF3buq5Yz2qvzOQ+eK/rDz0sJ+b5gbNmQuWYOrKqYvdtqG6Ny5w4ZVAo
uoXg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVWpdDExzezbRKnsZx0DrTOxdmNmN6DkvoI35WT4AONpJ7OJjMEPnOVLwCXlQQ3sOzX9uFvLhc6ZnmQCtu1ExxNYZM5f3Y=
X-Gm-Message-State: AOJu0YzdbtXmueCcZdbDPwVeVm4VqCRvBmfQUr/xL5pK+Yq61XUzoSqN
VZTxd3VWkAH7SEACfBFjYTgqtOBLrAVZsI1I3sqEmtFRnFfqp64S
X-Google-Smtp-Source: AGHT+IGS1qXfFmrJseqMiPHe92uDJROmyHypo90z6U8nU4lQfSX/rOxPC9d3NxJBFjQZt87k7xxA7g==
X-Received: by 2002:ac8:5c15:0:b0:430:ea45:75e8 with SMTP id i21-20020ac85c15000000b00430ea4575e8mr343519qti.60.1711654165230;
Thu, 28 Mar 2024 12:29:25 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:ac8:7c95:0:b0:432:b2f9:64f4 with SMTP id y21-20020ac87c95000000b00432b2f964f4ls1095603qtv.2.-pod-prod-05-us;
Thu, 28 Mar 2024 12:29:24 -0700 (PDT)
X-Received: by 2002:a05:620a:4610:b0:78a:7495:aff8 with SMTP id br16-20020a05620a461000b0078a7495aff8mr1294qkb.1.1711654164421;
Thu, 28 Mar 2024 12:29:24 -0700 (PDT)
Received: by 2002:a05:620a:28d0:b0:78a:4813:d207 with SMTP id af79cd13be357-78bc5d1eca3ms85a;
Thu, 28 Mar 2024 12:13:51 -0700 (PDT)
X-Received: by 2002:a67:f14a:0:b0:476:c40b:e717 with SMTP id t10-20020a67f14a000000b00476c40be717mr109430vsm.0.1711653230507;
Thu, 28 Mar 2024 12:13:50 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1711653230; cv=none;
d=google.com; s=arc-20160816;
b=uziECJu09CW46siNrw/gQpMwCNjYdonNfkhNfMQQOwGlJbqO+EJt0YsWnRE5Kt0q9A
McKUHVz+ymL+WWnDh6UL67qLesuqQVAdp+Vml7dEkJy70QHY4TX/SWTFJrUIhhpP2iRL
5E6FUCCamQuCPKuFF9pFwTukAEaYsyef/oOQHwxmQA5nxK0xxHMAAfH0yig2pZJsISXV
Desas9Zrncsid2eKJbStAqlPAMG/SR6I42E7mrBC6c1lN8N6gwXq9LMJiZEJxjATS+D4
g2ZXn6UCYrH8/OCEjkAb9cg1xsRPd6r3U+rFJznN7v1dL8LQMsLeziny3Akb+Wj4cG79
FNqw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:dkim-signature;
bh=dAXNhD2yxvYAvpCnsEX8QEKTf+zvey7MY0afHPQ/UmE=;
fh=yPd8HNyAt94w6+9mawPnFhKq8crEnOt8R5D/kg3m3ro=;
b=zIxseMLm+pqD0LDiznlOOJDRx2v11jiirJzJA2qDVsavg9e4TMzVEzFiumN8yMxq3t
jMPCkiOjH4JMcN8/3Ub2xtXGVHfcbdeS4bkodMt5eK8lqLuj1rrtBxZisX3Pf/2reTrU
/bQSCL9tTXJeUtbwAdlzN5Pf4Q1ABMnbx/HervIjsuQOGKeWFfDXQn8XRxjy5jXXCog/
V9ul1jh/mdyuOz+FeIpRbbstzCHTtrlSDFA2Kn7YVeXi+98jBywu9jNIZyy45kvIZhoR
07GPzsW4sVAzBj8TnZjWe63mO9Oe8OO+K4cja6mO7FNa9sq8IrmhqEx8kMBn7ZPKhrAh
urGQ==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@gmail.com header.s=20230601 header.b=LeZC+T9y;
spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::d29 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com;
dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com. [2607:f8b0:4864:20::d29])
by gmr-mx.google.com with ESMTPS id d13-20020a056102148d00b00476b8a1fbefsi239365vsv.0.2024.03.28.12.13.50
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Thu, 28 Mar 2024 12:13:50 -0700 (PDT)
Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::d29 as permitted sender) client-ip=2607:f8b0:4864:20::d29;
Received: by mail-io1-xd29.google.com with SMTP id ca18e2360f4ac-7c89cd8df36so31732739f.1
for <bitcoindev@googlegroups.com>; Thu, 28 Mar 2024 12:13:50 -0700 (PDT)
X-Received: by 2002:a6b:e71a:0:b0:7d0:3d39:5fbc with SMTP id
b26-20020a6be71a000000b007d03d395fbcmr113920ioh.1.1711653229756; Thu, 28 Mar
2024 12:13:49 -0700 (PDT)
MIME-Version: 1.0
References: <Zfg/6IZyA/iInyMx@petertodd.org> <0a377ddb-b001-41ba-9208-27b3fa059bb5n@googlegroups.com>
<ZgQZUOCc/dSjKMoL@petertodd.org> <CALZpt+GOCiwYdK4vfkODrT0Sx6HxCAuvhVqa1c5o3Xjy03OiAQ@mail.gmail.com>
<ZgV+Rk0m4azlbRZP@petertodd.org>
In-Reply-To: <ZgV+Rk0m4azlbRZP@petertodd.org>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 28 Mar 2024 19:13:38 +0000
Message-ID: <CALZpt+H2B1pSbqNa9phxZMxHX+30AiDqX7TgiRjH4rtirLwb9g@mail.gmail.com>
Subject: Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000bd0c740614bd5289"
X-Original-Sender: antoine.riard@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@gmail.com header.s=20230601 header.b=LeZC+T9y; spf=pass
(google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::d29
as permitted sender) smtp.mailfrom=antoine.riard@gmail.com; dmarc=pass
(p=NONE sp=QUARANTINE dis=NONE) header.from=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 (/)
--000000000000bd0c740614bd5289
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Peter,
Answering the latest 2 emails.
> Indeed, at this point I strongly suspect had I instead lobbied for a fix
> privately, given that one obvious mitigation is replace-by-fee-rate, I'd
> instead just get accused of nefarious behavior for not doing so openly.
I'll confirm publicly again that transaction-relay bandwidth DoS risks have
been
known or suspected by some senior developers for a while, including
sometimes
mentioned half-way on the Bitcoin Core GH repository years ago.
> Correct me if I'm wrong. But I don't believe that the
`dust_limit_satoshis`
> value can be changed on an existing channel.
> It *should* be possible to change on an existing channel, as the economic
dust
> limit is fee-rate dependent. But the protocol does not support that yet
IIUC.
This is correct, it cannot be changed once it has been negotiated at
opening flow.
Per-BOLT3 "Commitment Transaction Construction", the dust HTLCs are trimmed
and
the amount added to the commitment transaction absolute fee.
This ability can let you generate an ascending feerate range of commitment
transactions:
- state_1, size 1000 kb, 1 trimmed HTLC ~500 sats absolute fee
- state_2, size 900 kb, 2 trimmed HTLC ~1000 sats absolute fee
- state_3, size 800 kb, 3 trimmed HTLC ~1500 sats absolute fee
- etc
Non-dust HTLC fully materializing on the commitment transaction can be
added at wish to
adjust commitment transaction size if you're using a public channel used
for routing, without
the "honest interactivity" of your counterparty.
> There's also a convenience aspect to this: large mempools are convenient
for
> transaction senders, as it allows them to go off line after sending
> transactions that aren't going to be mined in the near future. If we had =
a
> world of purely always-online transaction senders, mempools could be
smaller.
Yes. This is a good question if a world of common size mempool for hobbyist
full-nodes can still be the network standard in the evolving world of today
where
re-broadcasting and pricing the next few blocks become more done by
transaction
issuers, evicting transactions without high odds to be mined in the near
future.
Said differently, Bitcoin clients with high-timevalue preferences for their
use-cases
are out-pricing Bitcoin clients with low-timevalue preferences from network
mempools.
> Modulo economic irrationalities with differently sized txs like the Rule
#6
> attack, the proof-of-UTXO is almost economically paid even when mempools
are
> partitioned because the bandwidth used by a given form of a transaction i=
s
> limited to the % of peers that relay it. Eg if I broadcast TxA to 50% of
nodes,
> and TxB to the other 50%, both spending the same txout, the total cost/KB
used
> in total would exactly the same... except that nodes have more than one
peer.
> This acts as an amplification fator to attacks depending on the exact
topology
> as bandwidth is wasted in proportion to the # of peers txs need to be
broadcast
> too. Basically, a fan-out factor.
> If the # of peers is reduced, the impact of this type of attack is also
> reduced. Of course, a balance has to be maintained.
Sure, proof-of-UTXO is imperfectly economically charged, however I think
you can
re-use the same proof-of-UTXO for each subset of Sybilled transaction-relay
peers.
And for sure, # peers and network topology can be leveraged as
amplification factors
for this class of "free-relay" attacks. Balance would have to be find
compared to worthiness
of carried-on transaction-relay traffic.
> Oh, and to expand on this discussion a bit... Assuming that LN
implementations
> did enable this type of attack, I'll point out that it's essentially
based on
> having incoming liquidity, which is not free. Either you paid for it by
paying
> someone to open channels to you. Or you operated a lightning node that
provided
> sufficiently attractive survice that people chose to open channels to you=
.
> Either way getting that incoming capacity cost you money, probably at
similar
> if not worse rates than just borrowing BTC.
Yes, note I used the term "allocated" in one of my previous emails, which I
concede
is not well-defined and it's indeed dependent on Lightning channel network
dynamics.
I'll leave as an exercise to the reader to find common liquidity management
asymmetries
in today's LN implementation to be leveraged as a discount vector for
"free-relay" bandwidth
attacks at the transaction-relay network-level.
Best,
Antoine
Le jeu. 28 mars 2024 =C3=A0 14:27, Peter Todd <pete@petertodd.org> a =C3=A9=
crit :
> On Wed, Mar 27, 2024 at 07:17:24PM +0000, Antoine Riard wrote:
> > > I don't believe the other attacks in this attack class are even
> possible
> > to
> > fix. We just have to live with the fact that a degree of free relay is
> > always
> > going to be possible.
> >
> > See comments under proof-of-UTXO ownership as plausible mitigations.
> >
> > In anway, I think this is not the type of fixes we can land in a covert
> > fashion given the
> > order of magnitude of engineering effort and potential tx-relay network
> > impact.
>
> Indeed, at this point I strongly suspect had I instead lobbied for a fix
> privately, given that one obvious mitigation is replace-by-fee-rate, I'd
> instead just get accused of nefarious behavior for not doing so openly.
>
> > > Can you explain in more detail how exactly you'd pull that off? Are y=
ou
> > aware
> > of LN implementations that actually create feerate ascending LN states?
> >
> > I think you can create feerates ascending LN states with today's LN
> > implementations by playing with BOLT2's `dust_limit_satoshis`.
> > State 1 has 1 dust HTLC trimmed, state 2 has 2 dust HTLCs trimmed, ...
> > State N has N dust HTLCs trimmed.
>
> Correct me if I'm wrong. But I don't believe that the `dust_limit_satoshi=
s`
> value can be changed on an existing channel.
>
> It *should* be possible to change on an existing channel, as the economic
> dust
> limit is fee-rate dependent. But the protocol does not support that yet
> IIUC.
>
> > > Imagine if the mempool size was 1TB, an amount larger than the entire
> BTC
> > > blocksize to date. I think that example helps make it obvious that wi=
th
> > such an
> > > enormous mempool, there *must* be free relay attacks, because it's
> simply
> > > impossible for all broadcast transactions to even get mined.
> >
> > I think there is an interesting distinction that can be made between
> > mempool size
> > ressources dedicated to increase block template efficiency and minimum
> > mempool size
> > to just ensure you have good BIP152 compact block validation time.
> > Obviously if you're
> > aiming for the first, you're incentivized to offer "free-relay" bandwid=
th
> > to your peers and
> > increase your view of the ongoing transaction traffic.
>
> There's also a convenience aspect to this: large mempools are convenient
> for
> transaction senders, as it allows them to go off line after sending
> transactions that aren't going to be mined in the near future. If we had =
a
> world of purely always-online transaction senders, mempools could be
> smaller.
>
> > > All the existing replacement mechanisms _are_ basically a proof-of-UT=
XO
> > > ownership, because they're transactions spending UTXOs. The only
> question
> > is
> > > the details of how that proof works.
> >
> > Yeah somehow it's correct that any replacement mechanisms encompass a
> > proof-of-UTXO
> > ownership mechanism. Yet in a world you can partition mempool like you
> show
> > with your
> > for example, it's easy to make this proof-of-UTXO economically unpaid b=
y
> > the attacker. Asking
> > aged UTXOs attached to a replacement candidate could be make such proof
> > more robust, in
> > my understanding.
>
> I think you're missing a third aspect to this: # of peers.
>
> Modulo economic irrationalities with differently sized txs like the Rule =
#6
> attack, the proof-of-UTXO is almost economically paid even when mempools
> are
> partitioned because the bandwidth used by a given form of a transaction i=
s
> limited to the % of peers that relay it. Eg if I broadcast TxA to 50% of
> nodes,
> and TxB to the other 50%, both spending the same txout, the total cost/KB
> used
> in total would exactly the same... except that nodes have more than one
> peer.
> This acts as an amplification fator to attacks depending on the exact
> topology
> as bandwidth is wasted in proportion to the # of peers txs need to be
> broadcast
> too. Basically, a fan-out factor.
>
> If the # of peers is reduced, the impact of this type of attack is also
> reduced. Of course, a balance has to be maintained.
>
> I call the Rule #6 attack an economic irrationality because the higher
> fee-rate
> transaction should have replaced the low fee-rate transactions: it's the
> one
> that got mined, so bandwidth spend on the low fee-rate txs was clearly
> wasted,
> and miners lost out on some fees.
>
> --
> 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/CALZpt%2BH2B1pSbqNa9phxZMxHX%2B30AiDqX7TgiRjH4rtirLwb9g%40mail.g=
mail.com.
--000000000000bd0c740614bd5289
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Peter,<div><br></div><div>Answering the latest 2 emails=
.</div><div><br></div><div>> Indeed, at this point I strongly suspect ha=
d I instead lobbied for a fix<br>> privately, given that one obvious mit=
igation is replace-by-fee-rate, I'd<br>> instead just get accused of=
nefarious behavior for not doing so openly.<br></div><div><br></div><div>I=
'll confirm publicly again that transaction-relay bandwidth DoS risks h=
ave been</div><div>known or suspected by some senior=C2=A0developers for a =
while, including sometimes=C2=A0</div><div>mentioned half-way on the Bitcoi=
n Core GH repository years ago.</div><div><br></div><div>> Correct me if=
I'm wrong. But I don't believe that the `dust_limit_satoshis`</div=
>> value can be changed on an existing channel.<br><br>> It *should* =
be possible to change on an existing channel, as the economic dust<br>> =
limit is fee-rate dependent. But the protocol does not support that yet IIU=
C.<div><br></div><div>This is correct, it cannot be changed once it has bee=
n negotiated at opening flow.<br><div></div></div><div><br></div><div>Per-B=
OLT3 "Commitment Transaction=C2=A0Construction", the dust HTLCs a=
re trimmed and</div><div>the amount added to the commitment transaction abs=
olute fee.</div><div><br></div><div>This ability can let you generate an as=
cending feerate range of commitment transactions:</div><div>- state_1, size=
1000 kb, 1 trimmed HTLC ~500 sats absolute fee</div><div>- state_2, size 9=
00 kb, 2 trimmed HTLC ~1000 sats absolute fee</div><div>- state_3, size 800=
kb, 3 trimmed HTLC ~1500 sats absolute fee</div><div>- etc</div><div><br><=
/div><div>Non-dust HTLC fully materializing on the commitment transaction c=
an be added at wish to</div><div>adjust commitment transaction size =C2=A0i=
f you're using a public channel used for routing, without</div><div>the=
"honest interactivity" of your counterparty.</div><div><br></div=
><div>> There's also a convenience aspect to this: large mempools ar=
e convenient for<br>> transaction senders, as it allows them to go off l=
ine after sending<br>> transactions that aren't going to be mined in=
the near future. If we had a<br>> world of purely always-online transac=
tion senders, mempools could be smaller.<br></div><div><br></div><div>Yes. =
This is a good question if a world of common size mempool for hobbyist</div=
><div>full-nodes can still be the network standard in the evolving world of=
today where=C2=A0</div><div>re-broadcasting and pricing the next few block=
s become more done by transaction</div><div>issuers, evicting transactions =
without high odds to be mined in the near future.</div><div><br></div><div>=
Said differently, Bitcoin clients with high-timevalue preferences for their=
use-cases</div><div>are out-pricing Bitcoin clients with low-timevalue pre=
ferences from network mempools.</div><div><br></div><div>> Modulo econom=
ic irrationalities with differently sized txs like the Rule #6<br>> atta=
ck, the proof-of-UTXO is almost economically paid even when mempools are<br=
>> partitioned because the bandwidth used by a given form of a transacti=
on is<br>> limited to the % of peers that relay it. Eg if I broadcast Tx=
A to 50% of nodes,<br>> and TxB to the other 50%, both spending the same=
txout, the total cost/KB used<br>> in total would exactly the same... e=
xcept that nodes have more than one peer.<br>> This acts as an amplifica=
tion fator to attacks depending on the exact topology<br>> as bandwidth =
is wasted in proportion to the # of peers txs need to be broadcast<br>> =
too. Basically, a fan-out factor.<br><br>> If the # of peers is reduced,=
the impact of this type of attack is also<br>> reduced. Of course, a ba=
lance has to be maintained.<br></div><div><br></div><div>Sure, proof-of-UTX=
O is imperfectly economically charged, however I think you can</div><div>re=
-use the same proof-of-UTXO for each subset of Sybilled transaction-relay p=
eers.</div><div><br></div><div>And for sure, # peers and network topology c=
an be leveraged as amplification factors</div><div>for this class of "=
free-relay" attacks. Balance would have to be find compared to worthin=
ess</div><div>of carried-on transaction-relay traffic.</div><div><br></div>=
<div>> Oh, and to expand on this discussion a bit... Assuming that LN im=
plementations<br>> did enable this type of attack, I'll point out th=
at it's essentially based on<br>> having incoming liquidity, which i=
s not free. Either you paid for it by paying<br>> someone to open channe=
ls to you. Or you operated a lightning node that provided<br>> sufficien=
tly attractive survice that people chose to open channels to you.<br>> E=
ither way getting that incoming capacity cost you money, probably at simila=
r<br>> if not worse rates than just borrowing BTC.<br></div><div><br></d=
iv><div>Yes, note I used the term "allocated" in one of my previo=
us emails, which I concede</div><div>is not well-defined and it's indee=
d dependent on Lightning channel network dynamics.</div><div><br></div><div=
>I'll leave as an exercise to the reader to find common liquidity manag=
ement asymmetries</div><div>in today's LN implementation to be leverage=
d as a discount vector for "free-relay" bandwidth</div><div>attac=
ks at the transaction-relay network-level.</div><div><br></div><div>Best,</=
div><div>Antoine</div><div><br></div><div><br></div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0jeu. 28 mars 20=
24 =C3=A0=C2=A014:27, 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;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">=
On Wed, Mar 27, 2024 at 07:17:24PM +0000, Antoine Riard wrote:<br>
> > I don't believe the other attacks in this attack class are ev=
en possible<br>
> to<br>
> fix. We just have to live with the fact that a degree of free relay is=
<br>
> always<br>
> going to be possible.<br>
> <br>
> See comments under proof-of-UTXO ownership as plausible mitigations.<b=
r>
> <br>
> In anway, I think this is not the type of fixes we can land in a cover=
t<br>
> fashion given the<br>
> order of magnitude of engineering effort and potential tx-relay networ=
k<br>
> impact.<br>
<br>
Indeed, at this point I strongly suspect had I instead lobbied for a fix<br=
>
privately, given that one obvious mitigation is replace-by-fee-rate, I'=
d<br>
instead just get accused of nefarious behavior for not doing so openly.<br>
<br>
> > Can you explain in more detail how exactly you'd pull that of=
f? Are you<br>
> aware<br>
> of LN implementations that actually create feerate ascending LN states=
?<br>
> <br>
> I think you can create feerates ascending LN states with today's L=
N<br>
> implementations by playing with BOLT2's `dust_limit_satoshis`.<br>
> State 1 has 1 dust HTLC trimmed, state 2 has 2 dust HTLCs trimmed, ...=
<br>
> State N has N dust HTLCs trimmed.<br>
<br>
Correct me if I'm wrong. But I don't believe that the `dust_limit_s=
atoshis`<br>
value can be changed on an existing channel.<br>
<br>
It *should* be possible to change on an existing channel, as the economic d=
ust<br>
limit is fee-rate dependent. But the protocol does not support that yet IIU=
C.<br>
<br>
> > Imagine if the mempool size was 1TB, an amount larger than the en=
tire BTC<br>
> > blocksize to date. I think that example helps make it obvious tha=
t with<br>
> such an<br>
> > enormous mempool, there *must* be free relay attacks, because it&=
#39;s simply<br>
> > impossible for all broadcast transactions to even get mined.<br>
> <br>
> I think there is an interesting distinction that can be made between<b=
r>
> mempool size<br>
> ressources dedicated to increase block template efficiency and minimum=
<br>
> mempool size<br>
> to just ensure you have good BIP152 compact block validation time.<br>
> Obviously if you're<br>
> aiming for the first, you're incentivized to offer "free-rela=
y" bandwidth<br>
> to your peers and<br>
> increase your view of the ongoing transaction traffic.<br>
<br>
There's also a convenience aspect to this: large mempools are convenien=
t for<br>
transaction senders, as it allows them to go off line after sending<br>
transactions that aren't going to be mined in the near future. If we ha=
d a<br>
world of purely always-online transaction senders, mempools could be smalle=
r.<br>
<br>
> > All the existing replacement mechanisms _are_ basically a proof-o=
f-UTXO<br>
> > ownership, because they're transactions spending UTXOs. The o=
nly question<br>
> is<br>
> > the details of how that proof works.<br>
> <br>
> Yeah somehow it's correct that any replacement mechanisms encompas=
s a<br>
> proof-of-UTXO<br>
> ownership mechanism. Yet in a world you can partition mempool like you=
show<br>
> with your<br>
> for example, it's easy to make this proof-of-UTXO economically unp=
aid by<br>
> the attacker. Asking<br>
> aged UTXOs attached to a replacement candidate could be make such proo=
f<br>
> more robust, in<br>
> my understanding.<br>
<br>
I think you're missing a third aspect to this: # of peers.<br>
<br>
Modulo economic irrationalities with differently sized txs like the Rule #6=
<br>
attack, the proof-of-UTXO is almost economically paid even when mempools ar=
e<br>
partitioned because the bandwidth used by a given form of a transaction is<=
br>
limited to the % of peers that relay it. Eg if I broadcast TxA to 50% of no=
des,<br>
and TxB to the other 50%, both spending the same txout, the total cost/KB u=
sed<br>
in total would exactly the same... except that nodes have more than one pee=
r.<br>
This acts as an amplification fator to attacks depending on the exact topol=
ogy<br>
as bandwidth is wasted in proportion to the # of peers txs need to be broad=
cast<br>
too. Basically, a fan-out factor.<br>
<br>
If the # of peers is reduced, the impact of this type of attack is also<br>
reduced. Of course, a balance has to be maintained.<br>
<br>
I call the Rule #6 attack an economic irrationality because the higher fee-=
rate<br>
transaction should have replaced the low fee-rate transactions: it's th=
e one<br>
that got mined, so bandwidth spend on the low fee-rate txs was clearly wast=
ed,<br>
and miners lost out on some fees.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">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/CALZpt%2BH2B1pSbqNa9phxZMxHX%2B30AiDqX7TgiRjH4rtirLwb=
9g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.=
google.com/d/msgid/bitcoindev/CALZpt%2BH2B1pSbqNa9phxZMxHX%2B30AiDqX7TgiRjH=
4rtirLwb9g%40mail.gmail.com</a>.<br />
--000000000000bd0c740614bd5289--
|