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
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
|
Delivery-date: Mon, 09 Jun 2025 03:54:53 -0700
Received: from mail-oo1-f63.google.com ([209.85.161.63])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDSKF7WH24FRB4P2TLBAMGQEMRH36XQ@googlegroups.com>)
id 1uOa9T-0005Qa-2s
for bitcoindev@gnusha.org; Mon, 09 Jun 2025 03:54:53 -0700
Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-6049acdc5c5sf3331159eaf.0
for <bitcoindev@gnusha.org>; Mon, 09 Jun 2025 03:54:51 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1749466485; cv=pass;
d=google.com; s=arc-20240605;
b=gPL3vens/1TR0g5Cz5x+jQHrQjAGwDrSWy84E6KZczWUEzhMR8ZUbl7CqjqnUgHWEa
9hsZRo7RfrqO/5lefSzg6e3R+WNDW7ZlwOQJIir1ZUBy9R3+C2xXzXScEsLAfz2g6K03
w3TXbEGi+3doIDKe2S8OAAGWuYt8gQYK9pJvo0u0lz2xMVQZ4YKEPMUsUvQVeQ6d3+SE
HP6unNuoK2Y9Q53C+wNFN1ZcLQeIHQqvEpxvVytQvbGQQ0n+BRd6XdrxoFLgur+8dnpu
a5P3T+Hk509xf7O/aNDzwkWvPCn4KcyOzh1W0KOxHoTl8gT+H1LYmJMKvURYN9G0QRww
+s9g==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
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=AmFwz+O2B4BLUGHzeILTyG8GBjZaXZQ3vA+TsKVqLoA=;
fh=tftEaol5rM//ey81/0UJMsiA0/hTWva3IQLGigKj9Dg=;
b=IExN7TYjDN0zqMq95m4zrbVUbuBTgeY3ZlhaHfJSXA8N94y5oTovO9TVn5z+iG7eAr
GWHlE3lKuGxN/s95QvePkqeN5+l95okiezN2LzjkD19e+Hui3SHMguWBjvYDmpKaOqr3
OO2EoOv4uBO3qZtUb8o7iOzZjGjeaqQ3whUXm3ZS+prDEwNzwpwR784dpr/px1pSEtA9
23Kfa6DatntKhRnt9bxY/zWsfFqG0T76KabNH7UrTGtVuf+PLS/6vjWTXJ3GZYlgl2jB
NKJZpTFZ72DIbdBGXxhZ4xPQJiib9htQzwb0Kr6j9QrPyeZY8IqQnhAfntKr2+YyzRhX
x16w==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@gmail.com header.s=20230601 header.b=j1wMvEKW;
spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f2b as permitted sender) smtp.mailfrom=chrisguida@gmail.com;
dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1749466485; x=1750071285; 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=AmFwz+O2B4BLUGHzeILTyG8GBjZaXZQ3vA+TsKVqLoA=;
b=k7n9Ddi82PgpaIRLl9YjwLOojnZrGJ0DXEfqXqox0MkXMucxWq2wXmboPnBPslZXkX
MN/KJUo9GsMaLqTpK024RU2W4t2wTVUnZl3E0w6MuU06Aiy94DeuVRJy0U1dPQPPv7L0
D+DD2gYX0cOxe/tAyeBXdhRMiwUioZHqZK9qyatdxkh32zjtQWTsYeDahBG+clHHt9e5
I1Z1B3no1+ytzpJeS9m7FghI+R0z1hRAWQXJQYizC6VVpnBQhZe3A6gZHYZ3pK+62Ib3
ZgpWH+tST9SfRrUXz0vnFOy01NpeK6lWjtmp0KlDkPdsrzfanMVyMUhiJFGglXCTq4+7
StZw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1749466485; x=1750071285; 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=AmFwz+O2B4BLUGHzeILTyG8GBjZaXZQ3vA+TsKVqLoA=;
b=Qe7kuQyZ96mWMYcfsmhpftYL1h4L1aV45p0VAQXZ8vDCCjgsc0MDOF1n23WG+/ZQ2E
wbWVM+Hz+933DNIAkmFigGIvZo1BKld/UBaqKT3Yel3LsoT/xfo5FGhxx427yM5XXbOY
r6JOV0yLxKyXZgU2xYa2HYHuE2vONPkEBcLCA8YDvvVvn8yaPXrDPO4ZmWipyn/GHQoS
M9Lt6SqL7Mmwtgi+g6I2q8sYj74p2dNNhSWmiX0QCvsHdHA8Q7dDpnAlenKkRcHmkKJg
GTInisJ8gPul1wmghiymxddEHXZAT8LNnROMHMNldxVSOTUKpfUOTUEC18opIFt8UpAm
ZfNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1749466485; x=1750071285;
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=AmFwz+O2B4BLUGHzeILTyG8GBjZaXZQ3vA+TsKVqLoA=;
b=wLHs7b1t4uyI6jUvqxNYALGZ4zD5bK1GzMi4bvilcw/7UDZOMsOx0OEYccYxUS91y8
7CrvaBp0zA34exnaC2si9oDOeYOgyTMD4RD8CQo0SMWCHr6sw6Qc+VrSsITkxMdudJz1
ehQ24p/QZXq7djlp1Oe9IXti+H9scvO+m1vhOR4d9vNidwptOjqv5egFcd6y27mbOPyI
iUW4dtkNS0Q+QcmB4N6MGFW+UIdAAekkzIEAt/oxew1jlI4Ec/egXi/TyY7Js786tzXd
3uIi0fEU8JRDTXsNYJZpHRF0K2UpWSkqRNOR1z/YA6ZZzPifvsyPLAtEN0rObG1xlV7M
PbjA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUTYq1vO0pqv7Hh3LxA6+w4/fF8UcE5GiDCPe417hU11a7crzMYGf4SNhdc0C1yspSDjKO7RMdSV+gv@gnusha.org
X-Gm-Message-State: AOJu0YzVrM0dAP+MyM3Kl2plnUAtaIJr+wjNsEQVn8+FscJCRBMKigO9
Q93oQUdAYZR0sP1ScEeEMmEYy7uTgPA62HUvtNO7ucRKsrCi446hFEbY
X-Google-Smtp-Source: AGHT+IFYr8jSrrAKqV5czpvHnq48x+Jnf06KYtH/eHywuCYGPQXXBC58vYQ9YJn0+eo5SV8yKwFDjg==
X-Received: by 2002:a05:6871:3804:b0:2c1:e9a3:3ab3 with SMTP id 586e51a60fabf-2ea0135622emr8080695fac.33.1749466484981;
Mon, 09 Jun 2025 03:54:44 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfs9dbR2bT6R39n3jedyGCYLf4L6Q9t33QFcmtxC6Bzhg==
Received: by 2002:a05:6820:406:b0:60f:38a0:336 with SMTP id
006d021491bc7-60f38a003f2ls1524160eaf.2.-pod-prod-03-us; Mon, 09 Jun 2025
03:54:41 -0700 (PDT)
X-Received: by 2002:a05:6808:3c4c:b0:401:e949:6381 with SMTP id 5614622812f47-4090520072amr8775105b6e.19.1749466481662;
Mon, 09 Jun 2025 03:54:41 -0700 (PDT)
Received: by 2002:a05:6808:5068:b0:3fa:da36:efcd with SMTP id 5614622812f47-408f0237c79msb6e;
Wed, 4 Jun 2025 11:46:51 -0700 (PDT)
X-Received: by 2002:a05:6870:d183:b0:2c1:9897:dd24 with SMTP id 586e51a60fabf-2e9bf5a2417mr3093801fac.35.1749062810231;
Wed, 04 Jun 2025 11:46:50 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1749062810; cv=none;
d=google.com; s=arc-20240605;
b=Jp6H1O08Z8hoGuwkbwbSgPjdF8rdTfc2+7E9IeBJQB1hLXiX3nQsvkYSCadBKzFxN5
WeHTAoHgiJ3tRTCvbk7ZCSezV+y6ysV3WJq8EYqp3yOSqWToGQL4UYzurXXjcxelBHgj
1Vqo6M9ixLeak/v8UR+4IPcglNSyk4xgCijrhDCi+7VTv6Kp2rGEgY5+s3FEP/iZQWob
rFjRCj8frX58C6R7R3mUcNhzO9Z17RWfQ61qSO5vQE7eDDq5pKXjDG9VzXJEcQfXAykX
7KdDdYr7TTjub2GZGXtYgT0grS/JvjM5xGOUDDGcUc0LwcYWlCKWlf6sFXWveTs4wSEX
XtKQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:dkim-signature;
bh=9boVLZvfxJgFKIU/OJa7UVFPypP/30kIQeWBhwZzYv8=;
fh=ykxiNqjf//+BiDAW8efWJAjdCFW+S1iX6pn+7QgqWu4=;
b=dLTy0BBCy8WrVEZ07zRtpettUcjYCBeqSTSXJ0KFWgf1SuXnf8fVpcQg++pw7Gz+6K
AowM08+MJj/G+hM57dt4O89/EUPM2uQgrI1KKmg9ikWYleaBRFqI9P/jY3P2nLk85t12
s+uCkXlMF6POEggWV4lL+zupQq4VhdfME2+iBm9NaQcivh8QWQSkmwddS02SyLzUDFfw
qvVwEiIOStqqgYWw8juUHYWpvz5PZVTBCWVy98Tyt8Um8Xstoqt26WiG1oJRIAYjRRxG
ftHT/kJl/N+wmnMPBvt7mfRsiWWctfQmy1ECtZjMCExqiWtxAI1U3gxNbiuIB+/yNaY6
+Ugg==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@gmail.com header.s=20230601 header.b=j1wMvEKW;
spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f2b as permitted sender) smtp.mailfrom=chrisguida@gmail.com;
dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
dara=pass header.i=@googlegroups.com
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com. [2607:f8b0:4864:20::f2b])
by gmr-mx.google.com with ESMTPS id 586e51a60fabf-2e90644dc11si742866fac.1.2025.06.04.11.46.50
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Wed, 04 Jun 2025 11:46:50 -0700 (PDT)
Received-SPF: pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f2b as permitted sender) client-ip=2607:f8b0:4864:20::f2b;
Received: by mail-qv1-xf2b.google.com with SMTP id 6a1803df08f44-6fad3400ea3so2627706d6.0
for <bitcoindev@googlegroups.com>; Wed, 04 Jun 2025 11:46:50 -0700 (PDT)
X-Gm-Gg: ASbGncsfCnbXTnOkO2n7/JwfwygSBfjlzeeyc4BqJWFovdDRsKTt39UKh1C9e6SlteQ
gCBXDfX2tHbnLK/a1vX43jTWZ5qFhsR3MpOR+w1+sR3+7McolGNVOCgdcs1nFx5ZAhpzfC34q/u
1AQWtIm6IFl7JzjVlQ9ymE1/lQKAa9Df4q
X-Received: by 2002:ad4:5ccf:0:b0:6fa:c0c8:4666 with SMTP id
6a1803df08f44-6faf6e868ebmr49572526d6.11.1749062809323; Wed, 04 Jun 2025
11:46:49 -0700 (PDT)
MIME-Version: 1.0
References: <aDWfDI03I-Rakopb@petertodd.org> <CAHTn92zkmfw2KwZCTRyGhnYPASWBUoLaxV65ASYpPeBUpX1SWw@mail.gmail.com>
<CAAANnUwHcd1w6phwyfDKebzEabAtm=A3i2qkLDpJ9L47q75T9Q@mail.gmail.com> <4BA2B86E-3E4B-416B-9237-AFD66FC4E37A@sprovoost.nl>
In-Reply-To: <4BA2B86E-3E4B-416B-9237-AFD66FC4E37A@sprovoost.nl>
From: Chris Guida <chrisguida@gmail.com>
Date: Wed, 4 Jun 2025 12:44:27 -0600
X-Gm-Features: AX0GCFuEeLLAFhLA7SgL586rVbW9OK5Sgqdm_B5yYIHDWt3rVoTHdSpphODfLeM
Message-ID: <CAAANnUyCj2cAgAG-sDZi_xOHHoEf7YO10f4XdKmSZCEDC=Fx6g@mail.gmail.com>
Subject: Re: [bitcoindev] Censorship Resistant Transaction Relay - Taking out
the garbage(man)
To: Sjors Provoost <sjors@sprovoost.nl>
Cc: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="000000000000708ff00636c36b7d"
X-Original-Sender: ChrisGuida@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@gmail.com header.s=20230601 header.b=j1wMvEKW; spf=pass
(google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f2b
as permitted sender) smtp.mailfrom=chrisguida@gmail.com; dmarc=pass
(p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/)
--000000000000708ff00636c36b7d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Sjors, thanks for the thoughtful response.
>More importantly it doesn't contain any numerical analysis as to its
effectiveness.
Well, as I said, I think Peter's analysis is sufficient, and I don't think
there's much for me to add. It seems to me that Peter's analysis
effectively comes down to relative numbers of LR vs GM nodes. GM nodes will
always be able to detect LR nodes, but the reverse is not necessarily true.
To illustrate this point: once the arms race has advanced sufficiently, it
may only be possible to really detect the difference between GM and LR
*during* a spam attack, as spam filtration is just rate-limiting, not
censorship. This means that, since merely rate-limiting abusive transaction
types is sufficient to protect the network against spam attacks such as the
ones we saw from BRC-20 and Runes, GM nodes might relay *low volumes* of
spammy transaction types, because low-volume spam, while undesirable, is
not really harmful. Again, as I tried to emphasize in my prior message, the
goal is not to *censor*; the goal is to *rate-limit spam*.
Given this, it is unlikely that LR nodes will be able to reliably detect GM
nodes, except during high-volume spam attacks, and at that point, why is LR
still facilitating the attack?
>Presence on the OFAC list is an objective criterion. Your distinction
between "objective" and "subjective" seems rather arbitrary.
This is a valid criticism; you are correct that this point warrants
clarification.
When I say "subjective", what I mean is that some authority has arbitrarily
decided that certain transaction types are undesirable, without evidence of
actual harm to bitcoin. OFAC is an example of such an arbitrary criterion.
OFAC transactions do not harm bitcoin in any way, as bitcoin's purpose is
to be permissionless money. Thus bitcoin infrastructure providers should
not worry about whether some political authority has decided that certain
actors should not be able to send money. That is up to law enforcement, not
the payment network.
Conversely, inscriptions and runes are two examples of transaction types
that have produced *measurable harm* to the bitcoin network. This is not a
matter of subjective opinion, but rather of incontrovertible historical
fact. I have already produced evidence of this fact in my prior message,
which anyone can verify because it is public.
>In any case it's not relevant for the purpose of censorship resistance.
It's relevant, because certain transaction formats are known to be harmful
(ie those associated with Ponzi metaprotocols), and others are not. In the
context of censorship resistance, if transaction formats that have no
objective possibility of harming bitcoin are prohibited, then censorship
has occurred. On the other hand, if transaction formats that are
objectively known to be harmful are rate-limited, then no censorship has
occurred; rather, spam filtration has occurred. Again, I'm trying to draw a
clear distinction between censorship and spam filtration, because the
former should be considered harmful and the latter should be considered
good and necessary.
I hope that clarifies this point.
>The reality is that there are different groups using Bitcoin and they have
different opinions on which transactions it should include.
Yes, and we should rate-limit transaction formats where there exists a
rough consensus that they are harmful (rough consensus being a proxy for
objectivity), while we should not rate-limit transactions that objectively
do not cause harm. Groups that "use bitcoin" in objectively harmful ways
should not have a seat at the table.
>Governments are one such group and they could decide tomorrow to spin up a
bigger version Garbageman and disrupt the entire mempool. If they perceive
it as an attack on their interest.
Can you go more into detail about the attack that concerns you here? There
are a number of issues with the scenario you outlined here:
What is a "bigger version of Garbageman"? As I already explained above,
Garbageman does nothing to censor anything. It does not "disrupt the
mempool" at all. It merely acts as a counterbalance to LR, which has an
extremely liberal mempool policy. On the contrary, LR is "disrupting the
mempool" by filling it with junk. GM neutralizes this disruption.
Is your concern that the USG would spin up a bunch of GM nodes that don't
relay transactions from OFAC addresses? As I've already detailed, this
would be completely ineffective, as anyone can get a single transaction
confirmed if they want. There is no way the government could effect
censorship against OFAC addresses unless literally 100% of the hashrate is
filtering such transactions.
In addition to this, there have been pools (to wit, F2Pool and Mara) that
have started filtering OFAC transactions, and there was an immediate
backlash against this activity, because again, OFAC transactions are
objectively not harmful to bitcoin, and censoring them *would* be
objectively harmful to bitcoin. Neither of the pools mentioned above is
filtering OFAC transactions anymore. This is a well-documented example of
social pressure preventing mining pools from harming bitcoin in order to
bolster their medium-term profits.
>As a result everyone has to submit transactions directly to a handful of,
often US based, pools.
Can you elaborate? I'm not seeing how this would work. Again, as long as
there is one pool willing to confirm OFAC transactions, the censorship is
not effective. I'm not seeing how US authorities could compel users to use
only US-based pools.
>If we're going down the route of openly innovating attacks against the
mempool, we should also continue innovating countermeasures, as Peter Todd
did.
I am perfectly fine with devs continuing to innovate methods of avoiding
censorship on bitcoin; this will certainly come in handy if "authorities"
attempt to censor bitcoin. But again, I don't see GM as "innovating attacks
against the mempool", nor do I see it as a viable tool for censorship. GM
has exactly the same mempool policy as Knots, and no one considers Knots to
be "innovating attacks against the mempool". It just follows the same
effective mempool policy as has been in place for over a decade. GM is
merely a countermeasure against LR, which *is* a danger to bitcoin.
>This is extremely vague and avoids the question of effectiveness. What
percentage of attempted "spam" transactions are prevented from entering a
block? What's the average delay in seconds?
This would be hard to measure, because the rate-limiting comes from
increasing the cost in money, time, and frustration on the spammers. Since
I am not a spammer, it would be difficult for me to conduct an experiment
to see how fast my demand falls in proportion to the costs imposed. But it
would be completely absurd to imagine that demand for spam is completely
inelastic; that is, that demand would never fall regardless of the costs
imposed. Economic theory and historical evidence both soundly refute this
notion.
>You speak of "rate limiting", but delaying propagation doesn't rate limit
anything. Unless you completely block some percentage of transactions, the
same amount of spam ends up in blocks, just a little bit later. The rate,
e.g. gigabytes per months, stays the same.
Again, this is simply incorrect. Spam does not have inelastic demand. Spam
filtration is a deterrent, which means that its mechanism of action is
*precisely* that it reduces demand. You seem to be implying that, no matter
what the cost, a spammer who wants to get a transaction confirmed will
never give up. This claim is exceedingly dubious. If one analyzes the
problem in the context of supply and demand, it is not hard to understand
why.
If a certain percentage of the hashrate is confirming spam, let's say 20%,
then that implies that the cost to get a spam transaction mined is much
higher than the cost of a normal transaction. Specifically, since the
supply of block space available for normal transactions is 5x higher than
for spam transactions, we can expect the cost of a spam transaction to be
5x higher and/or to take 5x longer to confirm. This is just basic economics=
.
And again, it is a matter of uncontroversial historical fact that filters
reduce economic demand for the transaction formats they reject. See [0] for
stats about a filter that is doing a fantastic job.
>If the "spammers" use extremely naive software, perhaps they never try
again and the sybil attack was successful. But this assumes an adversary
who doesn't adapt, which is not a reasonable assumption.
The "adversary" here is scammers and their gullible marks. They can run
their Ponzis on other chains much more easily than they can run them on
bitcoin, and they are lazy. If we just treat them with the hostility they
deserve, they will just give up and spam some other chain, as they did from
2014-2023.
>Anyone would understand from their own experience if that if a transaction
doesn't go through, you try again. You don't just accept that you've been
rate limited.
Again, *to a point*. There is a certain threshold of costliness beyond
which people just say "man, this isn't worth it, let's go spam ETH
instead". And again, bitcoin achieved this for 9 years.
>The simplest next move would be for their software to just connect to more
Libre relay peers and broadcast the transaction again.
Yep, that's where Garbageman comes in! If all LR peers are eclipsed by GM
peers, then this does nothing.
>Or people can just spin up more Libre Relay nodes.
Who are these people? Altcoiners?? Yeah, right. Anyway, we can just spin up
more GM nodes.
>Both miners and issuers of various scam tokens have a monetary incentive
to do that.
If miners do this, then they are hostile. If >50% of miners are hostile,
then bitcoin is dead.
>Whereas proponents of filters are (so far) not willing to invest serious
money.
I wouldn't be so sure about that.
>E.g. when I challenged Luke Dashjr in an earlier post to reorg a single
block with spam, he didn't respond
As Peter and you yourself noted, this is unfair to Ocean.
>Worse, Ocean proactively offers "Core" [0] templates
Yes, this is another reason why it would be silly for Ocean to try to "do"
anything with its hashrate; a large portion of its hashpower is making its
own templates.
>Although running a node is cheap, if this becomes an arms race, the side
that actually spends money has the advantage.
I disagree. I think the side that wants bitcoin to survive has the
advantage, because we are going down with the ship. As previously noted,
spammers are not at all invested in bitcoin's success. We can do this all
day. They can't.
>But let's say, after all this you find a way to make Garbageman effective,
that it actually causes and sustains an economically meaningful delay
between when a transaction is submitted to Libre Relay network and when its
included in a block. Then all you've achieved is an incentive to submit
directly to miners, making those miners more profitable. Congrats, you
didn't fix spam, you didn't rate limit anything and you made mining more
centralised.
Again, if miners are doing this, then they are hostile. If >50% of miners
are hostile, then we need to know *right now* because Nakamoto Consensus
falls apart if >50% of the hashrate is dishonest. We already trust the
miners not to try to 51% attack the network with their own new rules; why
is burying bitcoin under a mountain of garbage any different, except for
the fact that it's slower and less violent?
[0]: https://x.com/oomahq/status/1916793928025596338
On Tue, Jun 3, 2025 at 2:00=E2=80=AFAM Sjors Provoost <sjors@sprovoost.nl> =
wrote:
>
> Op 3 jun 2025, om 04:52 heeft Chris Guida <chrisguida@gmail.com> het
> volgende geschreven:
>
>
> Also, please let me know if this list is not the proper venue for this
> discussion. It gets kind of philosophical.
>
>
> More importantly it doesn't contain any numerical analysis as to its
> effectiveness.
>
> Spam filtration, conversely, is a rate-limiting of transactions based on
> objective criteria,
>
>
> Presence on the OFAC list is an objective criterion. Your distinction
> between "objective" and "subjective" seems rather arbitrary. In any case
> it's not relevant for the purpose of censorship resistance.
>
> The reality is that there are different groups using Bitcoin and they hav=
e
> different opinions on which transactions it should include.
>
> Governments are one such group and they could decide tomorrow to spin up =
a
> bigger version Garbageman and disrupt the entire mempool. If they perceiv=
e
> it as an attack on their interest. As a result everyone has to submit
> transactions directly to a handful of, often US based, pools.
>
> If we're going down the route of openly innovating attacks against the
> mempool, we should also continue innovating countermeasures, as Peter Tod=
d
> did.
>
> Garbageman restores the balance.
>
>
> This is extremely vague and avoids the question of effectiveness.
>
> What percentage of attempted "spam" transactions are prevented from
> entering a block? What's the average delay in seconds?
>
> You speak of "rate limiting", but delaying propagation doesn't rate limit
> anything. Unless you completely block some percentage of transactions, th=
e
> same amount of spam ends up in blocks, just a little bit later. The rate,
> e.g. gigabytes per months, stays the same.
>
> Peter's original email also doesn't answer this: presumably because he's
> trying to be generous:
>
> For a sybil attack to succeed against a non-listing node, every one of th=
e
> N
> outgoing connections must be either a sybil attacking node, or a listenin=
g
> node
> that itself has been defeated by sybil attack.
>
>
> "succeed" here just means the transaction doesn't reach a miner in the
> initial broadcast attempt.
>
> If the "spammers" use extremely naive software, perhaps they never try
> again and the sybil attack was successful. But this assumes an adversary
> who doesn't adapt, which is not a reasonable assumption.
>
> Anyone would understand from their own experience if that if a transactio=
n
> doesn't go through, you try again. You don't just accept that you've been
> rate limited.
>
> The simplest next move would be for their software to just connect to mor=
e
> Libre relay peers and broadcast the transaction again.
>
> Or people can just spin up more Libre Relay nodes. Both miners and issuer=
s
> of various scam tokens have a monetary incentive to do that. Whereas
> proponents of filters are (so far) not willing to invest serious money.
> E.g. when I challenged Luke Dashjr in an earlier post to reorg a single
> block with spam, he didn't respond [1]. Worse, Ocean proactively offers
> "Core" [0] templates. Although running a node is cheap, if this becomes a=
n
> arms race, the side that actually spends money has the advantage.
>
> But let's say, after all this you find a way to make Garbageman effective=
,
> that it actually causes and sustains an economically meaningful delay
> between when a transaction is submitted to Libre Relay network and when i=
ts
> included in a block. Then all you've achieved is an incentive to submit
> directly to miners, making those miners more profitable. Congrats, you
> didn't fix spam, you didn't rate limit anything and you made mining more
> centralised.
>
> - Sjors
>
> [0] https://ocean.xyz/docs/templateselection
> [1]
> https://gnusha.org/pi/bitcoindev/f348e4bf-ccc4-48e3-9745-ac72b1b131f5@app=
.fastmail.com/
>
> --
> 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
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/4BA2B86E-3E4B-416B-9237-AFD6=
6FC4E37A%40sprovoost.nl
> <https://groups.google.com/d/msgid/bitcoindev/4BA2B86E-3E4B-416B-9237-AFD=
66FC4E37A%40sprovoost.nl?utm_medium=3Demail&utm_source=3Dfooter>
> .
>
--=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 visit https://groups.google.com/d/msgid/bitcoindev/=
CAAANnUyCj2cAgAG-sDZi_xOHHoEf7YO10f4XdKmSZCEDC%3DFx6g%40mail.gmail.com.
--000000000000708ff00636c36b7d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Sjors, thanks for the thoughtful response.<br></di=
v><div><br></div><div>>More importantly it doesn't contain any numer=
ical analysis as to its effectiveness.</div><div><br></div><div>Well, as I =
said, I think Peter's analysis is sufficient, and I don't think the=
re's much for me to add. It seems to me that Peter's analysis effec=
tively comes down to relative numbers of LR vs GM nodes. GM nodes will alwa=
ys be able to detect LR nodes, but the reverse is not necessarily true. To =
illustrate this point: once the arms race has advanced sufficiently, it may=
only be possible to really detect the difference between GM and LR <i>duri=
ng</i> a spam attack, as spam filtration is just rate-limiting, not censors=
hip. This means that, since merely rate-limiting abusive transaction types =
is sufficient to protect the network against spam attacks such as the ones =
we saw from BRC-20 and Runes, GM nodes might relay <i>low volumes</i> of sp=
ammy transaction types, because low-volume spam, while undesirable, is not =
really harmful. Again, as I tried to emphasize in my prior message, the goa=
l is not to <i>censor</i>; the goal is to <i>rate-limit spam</i>.</div><div=
><br></div><div>Given this, it is unlikely that LR nodes will be able to re=
liably detect GM nodes, except during high-volume spam attacks, and at that=
point, why is LR still facilitating the attack?</div><div><br></div><div>&=
gt;Presence on the OFAC list is an objective criterion. Your distinction=20
between "objective" and "subjective" seems rather arbit=
rary.<br></div><div><br></div><div>This is a valid criticism; you are corre=
ct that this point warrants clarification.</div><div><br></div><div>When I =
say "subjective", what I mean is that some authority has arbitrar=
ily decided that certain transaction types are undesirable, without evidenc=
e of actual harm to bitcoin. OFAC is an example of such an arbitrary criter=
ion. OFAC transactions do not harm bitcoin in any way, as bitcoin's pur=
pose is to be permissionless money. Thus bitcoin infrastructure providers s=
hould not worry about whether some political authority has decided that ce=
rtain actors should not be able to send money. That is up to law enforcemen=
t, not the payment network.</div><div><br></div><div>Conversely, inscriptio=
ns and runes are two examples of transaction types that have produced <i>me=
asurable harm</i> to the bitcoin network. This is not a matter of subjectiv=
e opinion, but rather of incontrovertible historical fact. I have already p=
roduced evidence of this fact in my prior message, which anyone can verify =
because it is public.<br></div><div><br></div><div>>In any case
it's not relevant for the purpose of censorship resistance.</div><div>=
<br></div><div>It's relevant, because certain transaction formats are k=
nown to be harmful (ie those associated with Ponzi metaprotocols), and othe=
rs are not. In the context of censorship resistance, if transaction formats=
that have no objective possibility of harming bitcoin are prohibited, then=
censorship has occurred. On the other hand, if transaction formats that ar=
e objectively known to be harmful are rate-limited, then no censorship has =
occurred; rather, spam filtration has occurred. Again, I'm trying to dr=
aw a clear distinction between censorship and spam filtration, because the =
former should be considered harmful and the latter should be considered goo=
d and necessary.</div><div><br></div><div>I hope that clarifies this point.=
</div><div><br></div><div>>The reality is that there are different group=
s using Bitcoin and they=20
have different opinions on which transactions it should include.</div><div>=
<br></div><div>Yes, and we should rate-limit transaction formats where ther=
e exists a rough consensus that they are harmful (rough consensus being a p=
roxy for objectivity), while we should not rate-limit transactions that obj=
ectively do not cause harm. Groups that "use bitcoin" in objectiv=
ely harmful ways should not have a seat at the table.<br></div><div><br></d=
iv><div>>Governments are one such group and they could decide tomorrow t=
o spin up
a bigger version Garbageman and disrupt the entire mempool. If they=20
perceive it as an attack on their interest.<br></div><div><br></div><div>Ca=
n you go more into detail about the attack that concerns you here? There ar=
e a number of issues with the scenario you outlined here:</div><div><br></d=
iv><div>What is a "bigger version of Garbageman"? As I already ex=
plained above, Garbageman does nothing to censor anything. It does not &quo=
t;disrupt the mempool" at all. It merely acts as a counterbalance to L=
R, which has an extremely liberal mempool policy. On the contrary, LR is &q=
uot;disrupting the mempool" by filling it with junk. GM neutralizes th=
is disruption.</div><div><br></div><div>Is your concern that the USG would =
spin up a bunch of GM nodes that don't relay transactions from OFAC add=
resses? As I've already detailed, this would be completely ineffective,=
as anyone can get a single transaction confirmed if they want. There is no=
way the government could effect censorship against OFAC addresses unless l=
iterally 100% of the hashrate is filtering such transactions.</div><div><br=
></div><div>In addition to this, there have been pools (to wit, F2Pool and =
Mara) that have started filtering OFAC transactions, and there was an immed=
iate backlash against this activity, because again, OFAC transactions are o=
bjectively not harmful to bitcoin, and censoring them <i>would</i> be objec=
tively harmful to bitcoin. Neither of the pools mentioned above is filterin=
g OFAC transactions anymore. This is a well-documented example of social pr=
essure preventing mining pools from harming bitcoin in order to bolster the=
ir medium-term profits.<br></div><div><br></div><div>>As a result everyo=
ne has to=20
submit transactions directly to a handful of, often US based, pools.</div><=
div><br></div><div>Can you elaborate? I'm not seeing how this would wor=
k. Again, as long as there is one pool willing to confirm OFAC transactions=
, the censorship is not effective. I'm not seeing how US authorities co=
uld compel users to use only US-based pools.</div><div><br></div><div>>I=
f we're going down the route of openly innovating attacks against the=
=20
mempool, we should also continue innovating countermeasures, as Peter=20
Todd did.</div><div><br></div><div>I am perfectly fine with devs continuing=
to innovate methods of avoiding censorship on bitcoin; this will certainly=
come in handy if "authorities" attempt to censor bitcoin. But ag=
ain, I don't see GM as "innovating attacks against the mempool&quo=
t;, nor do I see it as a viable tool for censorship. GM has exactly the sam=
e mempool policy as Knots, and no one considers Knots to be "innovatin=
g attacks against the mempool". It just follows the same effective mem=
pool policy as has been in place for over a decade. GM is merely a counterm=
easure against LR, which <i>is</i> a danger to bitcoin.</div><div><br></div=
><div>>This is extremely vague and avoids the question of effectiveness.=
What percentage of attempted "spam" transactions are prevented f=
rom entering a block? What's the average delay in seconds?</div><div><b=
r></div><div>This would be hard to measure, because the rate-limiting comes=
from increasing the cost in money, time, and frustration on the spammers. =
Since I am not a spammer, it would be difficult for me to conduct an experi=
ment to see how fast my demand falls in proportion to the costs imposed. Bu=
t it would be completely absurd to imagine that demand for spam is complete=
ly inelastic; that is, that demand would never fall regardless of the costs=
imposed. Economic theory and historical evidence both soundly refute this =
notion.</div><div><br></div><div>>You speak of "rate limiting"=
, but delaying propagation doesn't rate=20
limit anything. Unless you completely block some percentage of=20
transactions, the same amount of spam ends up in blocks, just a little=20
bit later. The rate, e.g. gigabytes per months, stays the same.</div><div><=
br></div><div>Again, this is simply incorrect. Spam does not have inelastic=
demand. Spam filtration is a deterrent, which means that its mechanism of =
action is <i>precisely</i> that it reduces demand. You seem to be implying =
that, no matter what the cost, a spammer who wants to get a transaction con=
firmed will never give up. This claim is exceedingly dubious. If one analyz=
es the problem in the context of supply and demand, it is not hard to under=
stand why.</div><div><br></div><div>If a certain percentage of the hashrate=
is confirming spam, let's say 20%, then that implies that the cost to =
get a spam transaction mined is much higher than the cost of a normal trans=
action. Specifically, since the supply of block space available for normal =
transactions is 5x higher than for spam transactions, we can expect the cos=
t of a spam transaction to be 5x higher and/or to take 5x longer to confirm=
. This is just basic economics.</div><div><br></div><div>And again, it is a=
matter of uncontroversial historical fact that filters reduce economic dem=
and for the transaction formats they reject. See [0] for stats about a filt=
er that is doing a fantastic job.</div><div><br></div><div>>If the "=
;spammers" use extremely naive software, perhaps they never try=20
again and the sybil attack was successful. But this assumes an adversary
who doesn't adapt, which is not a reasonable assumption.</div><div><br=
></div><div>The "adversary" here is scammers and their gullible m=
arks. They can run their Ponzis on other chains much more easily than they =
can run them on bitcoin, and they are lazy. If we just treat them with the =
hostility they deserve, they will just give up and spam some other chain, a=
s they did from 2014-2023.</div><div><br></div><div>>Anyone would unders=
tand from their own experience if that if a=20
transaction doesn't go through, you try again. You don't just accep=
t=20
that you've been rate limited.</div><div><br></div><div>Again, <i>to a =
point</i>. There is a certain threshold of costliness beyond which people j=
ust say "man, this isn't worth it, let's go spam ETH instead&q=
uot;. And again, bitcoin achieved this for 9 years.<br></div><div><br></div=
><div>>The simplest next move would be for their software to just connec=
t to=20
more Libre relay peers and broadcast the transaction again.</div><div><br><=
/div><div>Yep, that's where Garbageman comes in! If all LR peers are ec=
lipsed by GM peers, then this does nothing.</div><div><br></div><div>>Or=
people can just spin up more Libre Relay nodes.</div><div><br></div><div>W=
ho are these people? Altcoiners?? Yeah, right. Anyway, we can just spin up =
more GM nodes.<br></div><div><br></div><div>>Both miners and issuers of =
various scam tokens have a monetary incentive to do that. <br></div><div><b=
r></div><div>If miners do this, then they are hostile. If >50% of miners=
are hostile, then bitcoin is dead.</div><div><br></div><div>>Whereas pr=
oponents of filters are (so far) not willing to invest serious money.</div>=
<div><br></div><div>I wouldn't be so sure about that.</div><div><br></d=
iv><div>>E.g. when I challenged Luke Dashjr in an earlier post to reorg =
a single block with spam, he didn't respond</div><div><br></div><div>As=
Peter and you yourself noted, this is unfair to Ocean.</div><div><br></div=
><div>>Worse, Ocean proactively offers "Core" [0] templates</d=
iv><div><br></div><div>Yes, this is another reason why it would be silly fo=
r Ocean to try to "do" anything with its hashrate; a large portio=
n of its hashpower is making its own templates.<br></div><div><br></div><di=
v>>Although running a node is cheap, if this becomes an arms race, the s=
ide that actually spends money has the advantage.</div><div><br></div><div>=
I disagree. I think the side that wants bitcoin to survive has the advantag=
e, because we are going down with the ship. As previously noted, spammers a=
re not at all invested in bitcoin's success. We can do this all day. Th=
ey can't.<br></div><div><br></div><div>>But let's say, after all=
this you find a way to make Garbageman=20
effective, that it actually causes and sustains an economically=20
meaningful delay between when a transaction is submitted to Libre Relay=20
network and when its included in a block. Then all you've achieved is a=
n
incentive to submit directly to miners, making those miners more=20
profitable. Congrats, you didn't fix spam, you didn't rate limit=20
anything and you made mining more centralised.</div><div><br></div><div>Aga=
in, if miners are doing this, then they are hostile. If >50% of miners a=
re hostile, then we need to know <i>right now</i> because Nakamoto Consensu=
s falls apart if >50% of the hashrate is dishonest. We already trust the=
miners not to try to 51% attack the network with their own new rules; why =
is burying bitcoin under a mountain of garbage any different, except for th=
e fact that it's slower and less violent?<br></div><div><br></div><div>=
[0]: <a href=3D"https://x.com/oomahq/status/1916793928025596338">https://x.=
com/oomahq/status/1916793928025596338</a></div></div><br><div class=3D"gmai=
l_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue=
, Jun 3, 2025 at 2:00=E2=80=AFAM Sjors Provoost <<a href=3D"mailto:sjors=
@sprovoost.nl">sjors@sprovoost.nl</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div><br><div><blockquote type=3D"cite"><d=
iv>Op 3 jun 2025, om 04:52 heeft Chris Guida <<a href=3D"mailto:chrisgui=
da@gmail.com" target=3D"_blank">chrisguida@gmail.com</a>> het volgende g=
eschreven:</div></blockquote><div><br></div><blockquote type=3D"cite">Also,=
please let me know if this list is not the proper venue for this discussio=
n. It gets kind of philosophical.</blockquote><div><br></div>More important=
ly it doesn't contain any numerical analysis as to its effectiveness.</=
div><div><br></div><div><blockquote type=3D"cite">Spam filtration, converse=
ly, is a rate-limiting of transactions based on objective criteria,</blockq=
uote><br></div><div>Presence on the OFAC list is an objective criterion. Yo=
ur distinction between "objective" and "subjective" see=
ms rather arbitrary. In any case it's not relevant for the purpose of c=
ensorship resistance.</div><div><br></div><div>The reality is that there ar=
e different groups using Bitcoin and they have different opinions on which =
transactions it should include.</div><div><br></div><div>Governments are on=
e such group and they could decide tomorrow to spin up a bigger version Gar=
bageman and disrupt the entire mempool. If they perceive it as an attack on=
their interest. As a result everyone has to submit transactions directly t=
o a handful of, often US based, pools.</div><div><br></div><div>If we'r=
e going down the route of openly innovating attacks against the mempool, we=
should also continue innovating countermeasures, as Peter Todd did.</div><=
div><br></div><div><blockquote type=3D"cite"><div><span style=3D"font-famil=
y:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-=
weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-tran=
sform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:n=
one;display:inline">Garbageman restores the balance.</span></div></blockquo=
te></div><div><br></div><div>This is extremely vague and avoids the questio=
n of effectiveness.</div><br><div>What percentage of attempted "spam&q=
uot; transactions are prevented from entering a block? What's the avera=
ge delay in seconds?</div><div><br></div><div>You speak of "rate limit=
ing", but delaying propagation doesn't rate limit anything. Unless=
you completely block some percentage of transactions, the same amount of s=
pam ends up in blocks, just a little bit later. The rate, e.g. gigabytes pe=
r months, stays the same.</div><div><br></div><div>Peter's original ema=
il also doesn't answer this: presumably because he's trying to be g=
enerous:</div><div><br></div><div></div><blockquote type=3D"cite"><div>For =
a sybil attack to succeed against a non-listing node, every one of the N<br=
>outgoing connections must be either a sybil attacking node, or a listening=
node<br>that itself has been defeated by sybil attack.=C2=A0</div></blockq=
uote><div><br></div><div>"succeed" here just means the transactio=
n doesn't reach a miner in the initial broadcast attempt.</div><div>=C2=
=A0</div><div>If the "spammers" use extremely naive software, per=
haps they never try again and the sybil attack was successful. But this ass=
umes an adversary who doesn't adapt, which is not a reasonable assumpti=
on.</div><div><br></div><div>Anyone would understand from their own experie=
nce if that if a transaction doesn't go through, you try again. You don=
't just accept that you've been rate limited.</div><div><br></div><=
div>The simplest next move would be for their software to just connect to m=
ore Libre relay peers and broadcast the transaction again.</div><div><br></=
div><div>Or people can just spin up more Libre Relay nodes. Both miners and=
issuers of various scam tokens have a monetary incentive to do that. Where=
as proponents of filters are (so far) not willing to invest serious money. =
E.g. when I challenged Luke Dashjr in an earlier post to reorg a single blo=
ck with spam, he didn't respond [1]. Worse, Ocean proactively offers &q=
uot;Core" [0] templates. Although running a node is cheap, if this bec=
omes an arms race, the side that actually spends money has the advantage.</=
div><div><br></div><div>But let's say, after all this you find a way to=
make Garbageman effective, that it actually causes and sustains an economi=
cally meaningful delay between when a transaction is submitted to Libre Rel=
ay network and when its included in a block. Then all you've achieved i=
s an incentive to submit directly to miners, making those miners more profi=
table. Congrats, you didn't fix spam, you didn't rate limit anythin=
g and you made mining more centralised.</div><div><br></div><div>- Sjors</d=
iv><div><br></div><div>[0]=C2=A0<a href=3D"https://ocean.xyz/docs/templates=
election" target=3D"_blank">https://ocean.xyz/docs/templateselection</a></d=
iv><div>[1]=C2=A0<a href=3D"https://gnusha.org/pi/bitcoindev/f348e4bf-ccc4-=
48e3-9745-ac72b1b131f5@app.fastmail.com/" target=3D"_blank">https://gnusha.=
org/pi/bitcoindev/f348e4bf-ccc4-48e3-9745-ac72b1b131f5@app.fastmail.com/</a=
></div><div><br></div></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" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/4BA2B86E-3E4B-416B-9237-AFD66FC4E37A%40sprovoost.nl?utm_medium=
=3Demail&utm_source=3Dfooter" target=3D"_blank">https://groups.google.c=
om/d/msgid/bitcoindev/4BA2B86E-3E4B-416B-9237-AFD66FC4E37A%40sprovoost.nl</=
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 visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAAANnUyCj2cAgAG-sDZi_xOHHoEf7YO10f4XdKmSZCEDC%3DFx6g%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAAANnUyCj2cAgAG-sDZi_xOHHoEf7YO10f4XdKmSZCEDC%3DFx6g%40ma=
il.gmail.com</a>.<br />
--000000000000708ff00636c36b7d--
|