summaryrefslogtreecommitdiff
path: root/6f/13a8675ef3b42f29887a5737d160dc1b1ad9fc
blob: acc5203fdfa11d38291b949fa8c1af03bf9085eb (plain)
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
Delivery-date: Wed, 24 Sep 2025 13:47:14 -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+bncBCJNLJPWXAIBBSFR2HDAMGQECINILOY@googlegroups.com>)
	id 1v1WOP-0003lj-Ql
	for bitcoindev@gnusha.org; Wed, 24 Sep 2025 13:47:14 -0700
Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-62354785b60sf111182eaf.2
        for <bitcoindev@gnusha.org>; Wed, 24 Sep 2025 13:47:13 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1758746828; cv=pass;
        d=google.com; s=arc-20240605;
        b=R2Cetzdn9YrWH6LwRtEyznQeUa75ng1HxrESqdCJvMTv1c/VLoIchc2/kwzIdumSIY
         anvlHtzQavE5DmUtOU8kYbiMFdqxRY6NaZSQEKBzBkVsKd2+i5lBrku50OD810cDIpm0
         gQjcJUVRq1wYz0ZniSPXf8qBnvGVkUDZtm1YesxMGmodxng/zjMvUNRnkIwJy6nypBc9
         XKw9FY0uIxIZIsk99YY5Nl3TH6qvm+L0U0Dw9XUVNq3iAFTaCQFFqYV4vEP5E8AC8AkF
         Y4F3pKr1TFzKmuL7aFd0a50uH8UVpqR+7oifPyAA/8edP3ykSB47wC1O3MmHVC3aKvJ4
         axuw==
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=MelD1fdK66k8wbOqViOyIP9i4gbVB73vIbG5EM0SKOc=;
        fh=qEt1wDVk7b5ZmYLrZKvl81YEFsCk2KlfHL6ghLnLxD8=;
        b=k2fqHZaAW2QjRYe8QumzCKoJHerzlV19iu0ycBweiXuU4/2NqhHiCVF7SGPY+K1wbQ
         CDNwkk8tnmMZAnTmV12Q3Or/vUENBOKOp33lZFVeNNgG/sqh74d9Wzefx0Lc893e4oSt
         p77TjJW4Kbcz2AJeCfQY54nmkpXNtwmojC8xJlppKK9nFpvSZocY5RRlA1XH8e6u3gdo
         LkOI53wZSxXdde7l7wXNwCNGCVT9rYr0hCIddniME4b/dYBnzOEi8IibU12PilqWATKg
         6fuOqcZIWrGO4S2yhLeU66gPu7XLnAI4UrFwlsD5LqxoRNm/FcavTRivs7gHcVnMkeiP
         xzTw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=ISVrADUL;
       spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52c as permitted sender) smtp.mailfrom=gmaxwell@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=1758746828; x=1759351628; 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=MelD1fdK66k8wbOqViOyIP9i4gbVB73vIbG5EM0SKOc=;
        b=KgOG9+wtqLYnNEhoKoiVY8dc1ajtMtkQFlG73/g0gyzA4vshEbIR7o25Th6ZDHXgSH
         SuOuwwSNdPnglnrr/5JiTQSRw1E9eJFlxt6HEjRmh47ze0gy4gZ0kbgBD4xnRjWKFSxX
         td5gnmGNqg4v+WvuvFHxuL4XXIXp821L9bgUk+EBTEFxbjOZubZyVbMEzqlXyVGXrrwc
         LstN1dxiTk7skUo3eUoo5D4KIOskwB6nKYyPhoeAR5vAh5cyLMDW48GzTmmkHUtddcSB
         DDXHl3mm+YwObJ+TrapD86BZjbSXp7m7u9e6Hz2lljSOnb+LrkIV+XAc4oFnGfod1ect
         4Q9w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758746828; x=1759351628; 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=MelD1fdK66k8wbOqViOyIP9i4gbVB73vIbG5EM0SKOc=;
        b=FWrrlc01389c8mTpAhSL0OReWQr9UbGaSb46xrpcdwfY7807oCvDh5XLSnoIHagGOI
         wpH2A4yp/oJI1De67kCxHG1brbkDhNIweOkLrgd0oZwl5rwVzdE65wZRb04CqUnts1r1
         hlCLX2t+t7krYMPL0vSjBU70NkIv+rUWyWXQBfnPRJebL2OE8BA7a2xeGHyTEBIlB8Cd
         PusRovpU9+33P9pKFNrcuMDT7/trqUfwR+KFPCTZ7/8vxEQYB8B3+4Wckn3vYdxU89BW
         yrMthcjXozmoS2IO9/02D0XAea67Dc1MnL0lifAkEEEd8xPY/FRanH6ZIM57DP607YMj
         NTeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758746828; x=1759351628;
        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=MelD1fdK66k8wbOqViOyIP9i4gbVB73vIbG5EM0SKOc=;
        b=rOjMG3KUKsQBPhBQ78x1fwuLaNuYjqC9NCyYLbfycG479qOTw6LrtO3hxv4nLjEfTY
         chvfy2QZO+aLV94STEL7i01K63ehP/r6oUDVOinKB0mqWlMWEjKf6youxzsEwKuR4l41
         xhaSRNDsDuq5E8M9q88I8r7xSVcng4vMEykjsXKdn9Z6GEk8qKnsFhCXfRXt4cIJSkH1
         cSQcjSNdLoQO0l4ab5VE6orpukqFBUjYIoAWGU7KTQpHjuccjm8Y+GXfrKDtZOuL98UQ
         iYwGuQUGIsNbtBS90010HhO3OH0nhICiXqI7OpSvPoHRj1SiYUj3Te5Gs/GhGF5Sq5jG
         4qAw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCW+ol02IOKJm64e2DSaHx4x3vyBtuM1RW/Pe7f8EFro9E8r9TXFYwy4HBD/v1PxkjSEWq2wl2VqnlLg@gnusha.org
X-Gm-Message-State: AOJu0YyO8O9ez0YJIFnwYurBvTI7Kl1iqW9wwbUjZ1SWtHTozXCUdJfd
	d+J2Y1xdexhNX/Tna+85WGUnwU8hV7IxNBkZcsG4ar4jJbE/VAPc0KLK
X-Google-Smtp-Source: AGHT+IEM1jG0d5biwQaYRxLx9eGkm1ptWSTUs4BL0NVXqh7Z8OdKbTGUBRjDrWXzFoQpwG0Iz1cHPg==
X-Received: by 2002:a05:6808:2286:b0:43d:2dc4:9d2e with SMTP id 5614622812f47-43f4cbf3283mr760336b6e.6.1758746827537;
        Wed, 24 Sep 2025 13:47:07 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd6J7gC0qfT1NSPAQADlxZcAgWYlsS35uEufygsmlnEuSw=="
Received: by 2002:a05:6870:5381:b0:30b:d6e4:3de6 with SMTP id
 586e51a60fabf-35ef077c70fls125512fac.2.-pod-prod-01-us; Wed, 24 Sep 2025
 13:47:04 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCXx2f+WXjSC6Zu9sxHexUNE/8N1yUEtwKZXJzClfPGaUmcRhnHBw6S3ZtFhAnYT3cGtSH82eliTPjD4@googlegroups.com
X-Received: by 2002:a05:6808:2286:b0:43d:2dc4:9d2e with SMTP id 5614622812f47-43f4cbf3283mr760248b6e.6.1758746823983;
        Wed, 24 Sep 2025 13:47:03 -0700 (PDT)
Received: by 2002:a05:6808:1881:b0:3f9:f009:458e with SMTP id 5614622812f47-43f3c2d667emsb6e;
        Wed, 24 Sep 2025 13:01:33 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCX9RSpdRjlP0XDQdJo02ZEAoSGCdgFIHYWIvgVKPe+W9Q2Jv9or5nlk+53SFPVO92LZyZN99mlTV5yP@googlegroups.com
X-Received: by 2002:a05:6a20:1590:b0:2da:3fe0:329a with SMTP id adf61e73a8af0-2e7d474b965mr953434637.37.1758744092360;
        Wed, 24 Sep 2025 13:01:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1758744092; cv=none;
        d=google.com; s=arc-20240605;
        b=X++ka1AfJpr0LSE5sQa/ATMLbBHiZ3Cyxa1sZQNWeScWg5EG95SpJkeEeVrIv1Z5M/
         /oJ8E35nbRqC4M4s8OeMEyBamTW1uaR44TJ/qFjP+Aa2aAKRBMqoBHkVfzzWkciiGIq2
         SetW2LPRq+VF26tDpspf5G9qURGK88nFjKHU03Gz2HfDAivJmWn1MGwTsBTmiTKYzFDb
         Nv8+6lX7/S/3zUaENXA6T1jzF+eBBQReRZlr6vlPdxKOkUPG2kIZVgt3c32Zawcfqtbk
         ESitHSNr5Ptlxr+zGRBDQ+L4ZSbJFmboQfcymiEU7GWmwVxS//INjuDPNKxpVnkEiPA4
         TNmg==
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=FLCempeL8jll4xdNObDJdEFFLm3thIqBA1iHbBaANY4=;
        fh=47VOY+qKHOuopk9TcuT2+/Jz69mAItpCv1ZH81FeTCs=;
        b=XvvPjsl+pojQJuY6jwoAg74jngPxWo7F8RqZzcWL5TCMPSlzQXz4DbcVYB0bsijlvl
         tEE+a5oQwT45XKeO5T1R6R+yiox3FRXu1GMWN5+xx+HEild64qm5e7P4hRVf4Jb9v2yF
         MZFvX5cxWh+So/kwvMYSEGu63mDtiTWmEIk3GD2Q51jzg80k5Aj53DH1g1ETGbmVpfTJ
         b9+4rytoAn93PWy6tWG/f6gjmG1IJqYEfyuSyeCLuoJvmhBkbBiL+kf6NefqbWYYn9+r
         aMjMiiTL9dqKfovz6p1bcJLpcAFQXMxHe6rXYqydJF1vc/psYKnYfhL9v5EuFnGYdlF3
         CK2g==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=ISVrADUL;
       spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52c as permitted sender) smtp.mailfrom=gmaxwell@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com. [2607:f8b0:4864:20::52c])
        by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-b57c539db71si6737a12.1.2025.09.24.13.01.32
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 24 Sep 2025 13:01:32 -0700 (PDT)
Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52c as permitted sender) client-ip=2607:f8b0:4864:20::52c;
Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-b49c1c130c9so165184a12.0
        for <bitcoindev@googlegroups.com>; Wed, 24 Sep 2025 13:01:32 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCW7CoxY6gaCVzc6I6wiqxC0sEor4BuZ8XeTmODQWTNg9CqhaAFH6Z1iLCjBBrQeMFxB0wboT+pZDHNv@googlegroups.com
X-Gm-Gg: ASbGncv1bPNsdmF86jzcpXVSiCL9125vIReFTe2+AVR8rgDQ2gKuVJJn9lteMDR466l
	+DOcjfgmMrWF17T9l9t7WWTVfzYUOdE7wTC/BrCiumweTZrsuBo+a0EO7gFw4YvWaO1DTtnXp80
	fdErIxMfS/hWjS18MY4T6qVrYi2LJ7V7smygVfqMQ1LU4m+ykCBAyOqdHI5WwHGgHGNrXp9T41V
	HcjAOE=
X-Received: by 2002:a17:903:3d0e:b0:271:5bde:697e with SMTP id
 d9443c01a7336-27ed49b9e58mr9706655ad.3.1758744091662; Wed, 24 Sep 2025
 13:01:31 -0700 (PDT)
MIME-Version: 1.0
References: <cbdab6fa-93bc-44c9-80f0-6c68c6554f56n@googlegroups.com>
 <CAAS2fgRFP+BJUZR7h01=7=qamD5qEW6OYJikTMR=5RkxTCEMZg@mail.gmail.com> <CAAANnUzf4SfgcixLuS0Uwe6pNyFWAtufzLuJrDdpnBwyU2bU7A@mail.gmail.com>
In-Reply-To: <CAAANnUzf4SfgcixLuS0Uwe6pNyFWAtufzLuJrDdpnBwyU2bU7A@mail.gmail.com>
From: Greg Maxwell <gmaxwell@gmail.com>
Date: Wed, 24 Sep 2025 20:01:20 +0000
X-Gm-Features: AS18NWB5lKRNtU7rcRaZGkACdRloPdeWXvobKyV-_IzvQ5KYtw09PzoAdKHmldM
Message-ID: <CAAS2fgSCORx7DHD6NCynh2rhnRbFgofLShZdqD9QwWO3fxyRWw@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies
 via User-Defined Scripts
To: Chris Guida <chrisguida@gmail.com>
Cc: me@drbonez.dev, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000d59cd6063f91843f"
X-Original-Sender: gmaxwell@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=ISVrADUL;       spf=pass
 (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::52c
 as permitted sender) smtp.mailfrom=gmaxwell@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 (/)

--000000000000d59cd6063f91843f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Because if you have a need to regulate traffic through your node there is
one, simple, perfectly effective way-- blocksonly.  Any other way is
ineffective (dramatically so if you wish to reduce traffic, as filtering
generally doesn't) and has collateral damage potential.

From the discussion in public the motivation to do otherwise is an attempt
to regulate the conduct of third parties. This is
fundamentally authoritarian, it would still be authoritarian even if
implemented in a distributed way.  E.g. if a theocratic populist movement
acted to prohibit sex for any purpose except reproduction (as advocated by
the most prominent filter propents) such as by public stonings of people
caught fornicating it would be just as authoritarian as if established by a
dictator.  In my view the fundamental nature of authoritarianism is people
who believe they know better to such an extent that they actively
interfere with the consensual conduct of third parties.  Historically most
authoritarianism has taken centralized forms, but this is partially just an
implementation detail similar to how cultures have adopted representative
democracy over direct democracy.  Centralized authoritarianism is itself
normally via a group like a state government, but just one with restricted
membership.   Technology can enable distributed authoritarianism like the
cancel culture of filter proponents.

More importantly, I disagree that there is any meaningful democratization
here-- to have any significant effects on the behavior of third parties,
some external mechanism must coordinate the content of filters.  Were this
not the case, you could simply say "my filtering node software exists and
is available, problem solved!" -- but you're not doing that, because to
have any effect (to the limited extent that you can) you essentially need
to convince everyone or at least most people to apply the same restrictions=
.

The fact that a mechanism isn't proposed here just obscures the matter
because one will arise out of necessity (or, alternatively, the proposal
would just not be used to a meaningful degree).  In essence the proposal
(or ones like it like the one being developed in knots) are technological
instruments of authoritarian censorship.  Sure they don't have all the
components yet to complete their natural conclusion.

> which is that the core maintainers decide all the defaults

Defaults? well duh, yes any author of software decides its defaults and
that is unchanged in this proposal.  Nor does it change persons own ability
to change their node behavior, as adjustments to policy are quite simple
and with the LLMs that power most filter advocates arguments even a
non-programmer can adjust them.  What it does accomplish over that is the
ability to take a live feed of censorship rules from a third party.

Why doesn't core ship blocks only?  Core attempts to model what will get
mined.  My blocks only recommendation was for parties that prioritize
conserving resources or avoiding various unconfirmed traffic over
accurately modeling what will get mined.







On Wed, Sep 24, 2025 at 7:16=E2=80=AFPM Chris Guida <chrisguida@gmail.com> =
wrote:

> Hi Aiden -
>
> This is a very interesting proposal! It certainly has the potential to
> reduce tension over mempool policy by removing decisions over mempool
> policy from bitcoin core's maintainers, who, if I understand correctly, a=
re
> not very interested in being the arbiters of policy over the bitcoin
> network anyway.
>
> This seems like an excellent way to let users decide which transactions
> they will relay and which ones they won't, which core maintainers have no
> control over anyway.
>
> I'm cautiously optimistic that this proposal can help break the logjam.
>
> Greg -
>
> I'm somewhat confused as to your reaction here. This proposal democratize=
s
> access to filter authorship; it does not seem in any way "authoritarian" =
to
> me. On the contrary, this proposal seems less "authoritarian" than the
> current state of affairs, which is that the core maintainers decide all t=
he
> defaults.
>
> >If you're not doing that you might as well set blocks only.
>
> Why is running blocksonly more beneficial than relaying some transactions
> and not others? Why does bitcoin core not default to blocksonly (or no
> filters at all) if partial filtration is undesirable?
>
> Kind regards,
>
> --Chris Guida
>
> On Wed, Sep 24, 2025 at 12:47=E2=80=AFPM Greg Maxwell <gmaxwell@gmail.com=
> wrote:
>
>> This appears to substantially misunderstands the purpose of the mempool
>> broadly in the network-- it's purpose is to model what will get mined.  =
If
>> you're not doing that you might as well set blocks only.
>> Significant discrepancies are harmful to the system and promote
>> centralization and fail to achieve a useful purpose in any case.  What
>> marginal benefits might be provided do not justify building and deployin=
g
>> the technological infrastructure for massive censorship.
>>
>> If you think this is important, I advise you to select another
>> cryptocurrency which is compatible with such authoritarian leanings.  --
>> though I am unsure if any exist since it is such a transparently pointle=
ss
>> direction.
>>
>>
>> On Wed, Sep 24, 2025 at 6:30=E2=80=AFPM Aiden McClelland <me@drbonez.dev=
> wrote:
>>
>>> Hi all,
>>>
>>> I'd like to share for discussion a draft BIP to allow for a modular
>>> mempool/relay policy: https://github.com/bitcoin/bips/pull/1985
>>>
>>> I think it could potentially reduce conflict within the community aroun=
d
>>> relay policy, as an alternative to running lots of different node
>>> implementations/forks when there are disagreements.
>>>
>>> I am working on a reference implementation using Bellard's QuickJS, but
>>> it has been almost a decade since I've written C++, so it's slow going =
and
>>> I'm sure doesn't follow best-practices. Once it's working, it can be
>>> cleaned up.
>>>
>>> Thanks,
>>> Aiden McClelland
>>>
>>> --
>>> 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/cbdab6fa-93bc-44c9-80f0-6c=
68c6554f56n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-6=
c68c6554f56n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to bitcoindev+unsubscribe@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRFP%2BBJUZR7h01%3D7%=
3DqamD5qEW6OYJikTMR%3D5RkxTCEMZg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRFP%2BBJUZR7h01%3D7=
%3DqamD5qEW6OYJikTMR%3D5RkxTCEMZg%40mail.gmail.com?utm_medium=3Demail&utm_s=
ource=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/=
CAAS2fgSCORx7DHD6NCynh2rhnRbFgofLShZdqD9QwWO3fxyRWw%40mail.gmail.com.

--000000000000d59cd6063f91843f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Because if you have a need to regulate traffic throug=
h your node there is one, simple, perfectly effective way-- blocksonly.=C2=
=A0 Any other way is ineffective (dramatically so if you wish to reduce tra=
ffic, as filtering generally doesn&#39;t) and has collateral damage potenti=
al.</div><div><br></div><div>From the discussion in public the motivation t=
o do otherwise is an attempt to regulate the conduct of third parties. This=
 is fundamentally=C2=A0authoritarian,=C2=A0it would still be authoritarian =
even if implemented in a distributed way.=C2=A0 E.g. if a theocratic populi=
st movement acted to prohibit sex for any purpose except reproduction (as a=
dvocated by the most prominent=C2=A0filter propents) such as by public ston=
ings of people caught fornicating it would be just as authoritarian as if e=
stablished by a dictator.=C2=A0 In my view the fundamental=C2=A0nature of a=
uthoritarianism is people who believe they know better to such an extent th=
at they actively interfere=C2=A0with the consensual=C2=A0conduct of third p=
arties.=C2=A0 Historically most authoritarianism=C2=A0has taken centralized=
 forms, but this is partially just an implementation detail similar to how =
cultures have adopted representative democracy over direct democracy.=C2=A0=
 Centralized authoritarianism is itself normally via a group like a state g=
overnment, but just one with restricted membership.=C2=A0 =C2=A0Technology =
can enable=C2=A0distributed authoritarianism=C2=A0like the cancel culture o=
f filter proponents.</div><div><br></div><div>More importantly, I disagree =
that there is any meaningful democratization here-- to have any significant=
 effects on the behavior of third parties, some external mechanism must coo=
rdinate the content of filters.=C2=A0 Were this not the case, you could sim=
ply say &quot;my filtering node software exists and is available, problem s=
olved!&quot; -- but you&#39;re not doing that, because to have any effect (=
to the limited extent that you can) you essentially need to convince everyo=
ne or at least most people to apply the same restrictions.</div><div><br></=
div><div>The fact that a mechanism isn&#39;t proposed here just obscures th=
e matter because one will arise out of necessity (or, alternatively, the pr=
oposal would just not be used to a meaningful degree).=C2=A0 In essence the=
 proposal (or ones like it like the one being developed in knots) are techn=
ological instruments of authoritarian censorship.=C2=A0 Sure they don&#39;t=
 have all the components yet to complete their natural conclusion.</div><di=
v><br></div><div>&gt;=C2=A0which is that the core maintainers decide all th=
e defaults</div><div><br></div><div>Defaults? well duh, yes any author of s=
oftware decides its defaults and that is unchanged in this proposal.=C2=A0 =
Nor does it change persons own ability to change their node behavior, as ad=
justments to policy are quite simple and with the LLMs that power most filt=
er advocates arguments even a non-programmer can adjust them.=C2=A0 What it=
 does accomplish over that is the ability to take a live feed of censorship=
 rules from a third party.</div><div><br></div><div>Why doesn&#39;t core sh=
ip blocks only?=C2=A0 Core attempts to model what will get mined.=C2=A0 My =
blocks only recommendation was for parties that prioritize conserving resou=
rces or avoiding various unconfirmed traffic over accurately modeling=C2=A0=
what will get mined.</div><div><br></div><div><br></div><div><br></div><div=
><br></div><div><br></div><div><br></div></div><br><div class=3D"gmail_quot=
e gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep =
24, 2025 at 7:16=E2=80=AFPM Chris Guida &lt;<a href=3D"mailto:chrisguida@gm=
ail.com">chrisguida@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Aiden - </div><div><b=
r></div><div>This is a very interesting proposal! It certainly has the pote=
ntial to reduce tension over mempool policy by removing decisions over memp=
ool policy from bitcoin core&#39;s maintainers, who, if I understand correc=
tly, are not very interested in being the arbiters of policy over the bitco=
in network anyway.</div><div><br></div><div>This seems like an excellent wa=
y to let users decide which transactions they will relay and which ones the=
y won&#39;t, which core maintainers have no control over anyway.</div><div>=
<br></div><div>I&#39;m cautiously optimistic that this proposal can help br=
eak the logjam.<br></div><div><br></div><div>Greg -</div><div><br></div><di=
v>I&#39;m somewhat confused as to your reaction here. This proposal democra=
tizes access to filter authorship; it does not seem in any way &quot;author=
itarian&quot; to me. On the contrary, this proposal seems less &quot;author=
itarian&quot; than the current state of affairs, which is that the core mai=
ntainers decide all the defaults.<br></div><div><br></div><div>&gt;If you&#=
39;re not doing that you might as well set blocks only.</div><div><br></div=
><div>Why is running blocksonly more beneficial than relaying some transact=
ions and not others? Why does bitcoin core not default to blocksonly (or no=
 filters at all) if partial filtration is undesirable?</div><div><br></div>=
<div>Kind regards,</div><div><br></div><div>--Chris Guida<br></div></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, =
Sep 24, 2025 at 12:47=E2=80=AFPM Greg Maxwell &lt;<a href=3D"mailto:gmaxwel=
l@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>This=
 appears to substantially=C2=A0misunderstands the purpose of the mempool br=
oadly in the network-- it&#39;s purpose is to model what will get mined.=C2=
=A0 If you&#39;re not doing that you might as well set blocks only.=C2=A0 S=
ignificant=C2=A0discrepancies=C2=A0are harmful to the system and promote ce=
ntralization=C2=A0and fail to achieve a useful purpose in any case.=C2=A0 W=
hat marginal benefits might be provided do not justify=C2=A0building and de=
ploying the technological=C2=A0infrastructure=C2=A0for massive censorship.<=
/div><div><br></div><div>If you think this is important, I advise you to se=
lect another cryptocurrency which is compatible with such authoritarian=C2=
=A0leanings.=C2=A0 -- though I am unsure if any exist since it is such a tr=
ansparently pointless direction.</div><div><br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep 24, 2025=
 at 6:30=E2=80=AFPM Aiden McClelland &lt;<a href=3D"mailto:me@drbonez.dev" =
target=3D"_blank">me@drbonez.dev</a>&gt; 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>Hi all,</div><div><br></div><div>I&#3=
9;d like to share for discussion a draft BIP to allow for a modular mempool=
/relay policy: <a href=3D"https://github.com/bitcoin/bips/pull/1985" target=
=3D"_blank">https://github.com/bitcoin/bips/pull/1985</a><br><br></div><div=
>I think it could potentially reduce conflict within the community around r=
elay policy, as an alternative to running lots of different node implementa=
tions/forks when there are disagreements.</div><div><br></div><div>I am wor=
king on a reference implementation using Bellard&#39;s QuickJS, but it has =
been almost a decade since I&#39;ve written C++, so it&#39;s slow going and=
 I&#39;m sure doesn&#39;t follow best-practices. Once it&#39;s working, it =
can be cleaned up.</div><div><br></div><div>Thanks,</div><div>Aiden McClell=
and<br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; 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/cbdab6fa-93bc-44c9-80f0-6c68c6554f56n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-6c68c6554f56n%40googlegrou=
ps.com</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; 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/CAAS2fgRFP%2BBJUZR7h01%3D7%3DqamD5qEW6OYJikTMR%3D5RkxTCEMZg%40ma=
il.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRFP%2BBJUZR7h01%3D7%3Dq=
amD5qEW6OYJikTMR%3D5RkxTCEMZg%40mail.gmail.com</a>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; 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/CAAS2fgSCORx7DHD6NCynh2rhnRbFgofLShZdqD9QwWO3fxyRWw%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAAS2fgSCORx7DHD6NCynh2rhnRbFgofLShZdqD9QwWO3fxyRWw%40mail.g=
mail.com</a>.<br />

--000000000000d59cd6063f91843f--