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
|
Delivery-date: Sun, 28 Sep 2025 17:07:58 -0700
Received: from mail-oa1-f61.google.com ([209.85.160.61])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBAABBU4347DAMGQEPBA3AHY@googlegroups.com>)
id 1v31Qs-0003KR-Bt
for bitcoindev@gnusha.org; Sun, 28 Sep 2025 17:07:58 -0700
Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-3800161d39bsf916303fac.3
for <bitcoindev@gnusha.org>; Sun, 28 Sep 2025 17:07:57 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1759104472; cv=pass;
d=google.com; s=arc-20240605;
b=J5v0NZt0fCUFQZroy8OOMT416rUdCKWTsiNmW+kgPDdOx+7yq99iYC5bOmGAoBx2B+
taagkrW7cYBmzZ9U/uIIAhyf4/WEscuQlqKy4JWW/aHlVKZrIdB+WWmY8g4GthrWlxhN
H4q6tWXnAkhRISIa7OAUYIsPEQLiQbbgFuFTt1zAAMDdFyG77pkIi0lSCzGiD8YSVYuH
0eOV1BGSx+qtALSsby6IC2YpxugdfsyRpX+wX6/N5tvfRr4RhxorK2nTKs5HyOQtXQM0
PkT00CGFtuXOGNRq1w1UvmLK3NQKZQn3cxVVVyWVxHMD9WNqjRRw3pS2cb69Q4xHysjb
59og==
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:in-reply-to:content-disposition
:mime-version:references:message-id:subject:to:from:date:sender
:dkim-signature;
bh=/ldOj+SRjZR5SPi2U7Bw3QkaeUsD5HMyE4wt5EguI80=;
fh=XTsizQjDU3/tkJEENj2hkdNpLCGTvx4Swyj72YhWdYk=;
b=ZC/BvXVeUgS54A6DurVdqj9XyhGHUmb5g4aHdBKiDwEGZ6nuzJIxaI/6GioB3a+2MY
8uAUCiRPVDInlnK0vaEaxrcTAPXxuMK4E3QxCxg1iirl9IR9KFc/L2nOQn2cqZvzWz/D
X+HLvroH+JJ/JHhr1VaJdlOdwX2ap37vI1QCAicVl9ClDOuYPn8FMo7mFVbegpAeAu0I
Fsh4xPw+N9DlChRj8WHp4FI00iA/Kmu/Ut9aEMapFhEOBvAKLEqd5ZNH/KcsDt57K+jo
uNjnhdxSbrg/M+Huoo05+rIjhMjvU1x3tuN0QL3sZ48sMnaNHOI5N+t4mDDgfxdDMNa8
UDog==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@mail.wpsoftware.net header.s=default header.b=kEL9pp9D;
spf=pass (google.com: domain of apoelstra@wpsoftware.net designates 66.183.0.127 as permitted sender) smtp.mailfrom=apoelstra@wpsoftware.net;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wpsoftware.net
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1759104472; x=1759709272; 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:in-reply-to:content-disposition:mime-version
:references:message-id:subject:to:from:date:sender:from:to:cc
:subject:date:message-id:reply-to;
bh=/ldOj+SRjZR5SPi2U7Bw3QkaeUsD5HMyE4wt5EguI80=;
b=vzCRe61myC+64GZGMWOy1Oq2q9elGvD38fVjOFkaK2UAsZf0nD7k9vy5im1H9ZC7Ds
Cllqcvejy2n+UZwEhgLeY3dDb80tZtDMvEv0fRjQruddpJ/o7he4ImVFo/3sGhc3yrn5
hPkJm3OIu5xwZGZ7cVbnqVIvWUj5l+8JEVf/zb6ytSityK2+aixvaF9Vwl58u/Ic2rnv
9LsYeYJ3HHo/bGpA3qC8s7o+NpvEz8CWCTH/2MHEJx2jxWshglYeSsLrko4qOCIWPtH1
53i7eA5WbzU7j9VM2kSJ+AvdrpBDiA/a+/rkesp2yENuEoulPGmcsfNHzkk5tb8uUEJO
7NuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759104472; x=1759709272;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:in-reply-to:content-disposition:mime-version
:references:message-id:subject:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=/ldOj+SRjZR5SPi2U7Bw3QkaeUsD5HMyE4wt5EguI80=;
b=olDm00LeHVs+4ob9FSWuBeBwb505chYOG7xBhmPZPquCkLm9xIgPrQ4lsvt4wNf4Tw
YloNDgf1TYMOmYacRYquefwv5z2cRTlt7D1be5RG0besYA/5R/39+Y4cjFnyfOuFwDYu
jy5RoRkQVgb1sKe87UEvA9/mds58prKxuH6rakfo+aNQpfdhSAkfotTpUG89XBGQrvXT
YIILNJEGhDRAmFZF0Ac2vDSKD4ZokyIW31Opzt8o2SU6Tj9sggb5uQbdM4zEDmO4vST9
YvuMe+n4Pylqcw0Z3GN42mSRxchmt7hteA8/DBXKm2klRuJsaUMIPvM2ogpMnLRUNVJt
Qh0g==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVUDySPXc0wwcsPW+s7DZJXPFI3/TW4+77xFmiI+jik4udxprHBpxhWD/7Abk5XzjYhvN2wt2UpOCcj@gnusha.org
X-Gm-Message-State: AOJu0Ywd/vrNmGqyRWVrpEftog1++nQ0s7PP6xH9ObQMG7vI9Cb3w0cP
J3JuKxSivfaUbrcUzm218hmFdhEhvvhP1Wjk4TXvR7rMDgrDX1YzCKdT
X-Google-Smtp-Source: AGHT+IGZ2nQjhFChyNltvYPJTzLPDSX1cMBM4B6ZE4ylsRzxJXh1b+bcmbO10LSTeNl22OXiPP5YYg==
X-Received: by 2002:a05:6870:6111:b0:321:8f88:a39c with SMTP id 586e51a60fabf-35eeb3f0976mr665904fac.47.1759104471330;
Sun, 28 Sep 2025 17:07:51 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd44nujHWbUiRcqNS+pKvHrINPgm+Avb5+yGSJ1oQXvOqg=="
Received: by 2002:a05:6870:178b:b0:363:4ae7:c37f with SMTP id
586e51a60fabf-3635945a0d0ls1973004fac.0.-pod-prod-05-us; Sun, 28 Sep 2025
17:07:47 -0700 (PDT)
X-Received: by 2002:a05:6808:4a4c:10b0:43f:4d50:3352 with SMTP id 5614622812f47-43f4d5035c6mr6795150b6e.31.1759104467103;
Sun, 28 Sep 2025 17:07:47 -0700 (PDT)
Received: by 2002:a05:620a:1a8c:b0:82b:15c1:88e9 with SMTP id af79cd13be357-8601c353ea0ms85a;
Sun, 28 Sep 2025 16:46:10 -0700 (PDT)
X-Received: by 2002:a05:6214:ca3:b0:7d4:e416:ac05 with SMTP id 6a1803df08f44-7fc10970574mr156953226d6.0.1759103169424;
Sun, 28 Sep 2025 16:46:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1759103169; cv=none;
d=google.com; s=arc-20240605;
b=WdnjAVrhpJduwKmCgpXleo2ds9Zo37Dtwa3TCNXe/y0ywDsT8NMRMztITasr3OOQyf
ODH0Am7dXd23J4cz3CzKHLQzFMclew6G1c0V1vR0Crpkh10Kot5Vki6fQropSi+7Z19A
w1MDLWshTPbiuEWwca/Ep8lMeX0yBzh6tmIq5+1ELHHo8LFP6PyFaL1IbyYbw+NjxKsG
Q1aHDmwO9STo8aJj3ZT8nifanRlJ0VyPU+d6kuBvuG87+UQQk97RIIZRgzeN9t+F0Mse
sciswpbJH094CEtgQ2bOaZnegwrcNbymqk+8LOrXzfUFcyqS1b2ZGgTM8OFX+xavzmSC
K+Ww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:to:from:dkim-signature:date;
bh=4itFHKENg9+Ypm1U6G8cGgqMhIuDmNdl5XEi8VsQpMw=;
fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=;
b=CSC5di/TH47sHcmFZMjFecWxJsltiWIy1T/Z96ASSNgxzoLjnGadGh9jCPkimf3H4s
0clAMLBtnJvav/OOk2zoUv9wR3xEShQPyDD8+4F+7bFnUtx1CTGtDPXXApetkW/quj4L
19Ub4zLEJheCiCFYBWRJBohb4J3CM23sQy32ly3OYkA++tYM6LX87b69JQ5fPJw8TlbQ
l2GLzfu6RRzWpvNzWAQLTecSzc/2a+JBMr/DBVeEGe6oiVar2ljmV631CCi0XcPBebQD
otQsaCSNmDIELtqQvhXwPT9oGrDYM7a05ZKV2FUegpJJszMIxSwXdzFfZclu7pvnez41
eqYg==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@mail.wpsoftware.net header.s=default header.b=kEL9pp9D;
spf=pass (google.com: domain of apoelstra@wpsoftware.net designates 66.183.0.127 as permitted sender) smtp.mailfrom=apoelstra@wpsoftware.net;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wpsoftware.net
Received: from mail.wpsoftware.net (s66-183-0-127.mail.wpsoftware.net. [66.183.0.127])
by gmr-mx.google.com with ESMTPS id 6a1803df08f44-8016823b11asi3848276d6.5.2025.09.28.16.46.09
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 28 Sep 2025 16:46:09 -0700 (PDT)
Received-SPF: pass (google.com: domain of apoelstra@wpsoftware.net designates 66.183.0.127 as permitted sender) client-ip=66.183.0.127;
Date: Sun, 28 Sep 2025 23:46:05 +0000
From: Andrew Poelstra <apoelstra@wpsoftware.net>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies
via User-Defined Scripts]
Message-ID: <aNnIvR5Naea8pXCe@mail.wpsoftware.net>
References: <aNaUjR7QTqWvtZLa@mail.wpsoftware.net>
<CAAANnUz3V-ciTB1+9tUz8yByhd66UpyPJTZEQFrPRMjLXZfdwQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="5eFL/aC/Ca8gVIfH"
Content-Disposition: inline
In-Reply-To: <CAAANnUz3V-ciTB1+9tUz8yByhd66UpyPJTZEQFrPRMjLXZfdwQ@mail.gmail.com>
X-Original-Sender: apoelstra@wpsoftware.net
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@mail.wpsoftware.net header.s=default header.b=kEL9pp9D;
spf=pass (google.com: domain of apoelstra@wpsoftware.net designates
66.183.0.127 as permitted sender) smtp.mailfrom=apoelstra@wpsoftware.net;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wpsoftware.net
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.8 (/)
--5eFL/aC/Ca8gVIfH
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
On Fri, Sep 26, 2025 at 03:50:09PM -0600, Chris Guida wrote:
>
> >Yes, it is a "new purpose" introduced almost a decade ago to allow Bitcoin
> to scale without unnecessarily causing load on nodes
>
> Yes, and my point here is that you seem to be implying that the *only*
> purpose of the mempool is to make blocks propagate faster, and if that were
> true, then I would agree with you that spam filters are harmful. But since
> the mempool predates CBR by several years, your claim cannot be true.
>
I certainly didn't mean to imply that the only purpose of the mempool
was to improve block propagation -- it is also useful for nodes to
validate transactions and cache signature validity and UTXO set updates,
something which filters are also harmful for.
<snip>
>
> Your point about node decentralization being paramount is also why core
> devs should listen to their users when they report UX difficulties. If the
> experience of running a node is bad, very few will do it. (I can assure you
> that the experience of running a useful merchant node is bad).
>
User experience is bad when every 10 minutes a block comes in and your
laptop fan spins up and your software freezes because your computer is
suddenly processing a whole block of transactions at once. It's bad when
Netflix needs to pause and re-cache every 10 minutes because your
network connection is saturated by a whole block.
Both of these things happened to me constantly before compact blocks.
<snip>
> >If the dust filter, transaction size filters, standardness limits, etc.,
> were being ignored by miners then they should be removed, yes.
>
> Really? This should be trivial to achieve simply by launching a shitcoin
> metaprotocol on top of one of these filtered tx formats. At that point node
> DoS attacks would become more commonplace, no?
>
> >Some of these exist for historical reasons and others for performance
> reasons, and in the latter case there might be a movement to enforce the
> old rules in consensus.
>
> Interesting, so you're saying if someone launches a shitcoin metaprotocol
> on top of txs that are DoS vectors, then that might generate support for
> the Great Consensus Cleanup? Hmm...
>
Yes, you could try something like this, though this plan has a movie-plot
level of complexity and you are likely to fail at the first step where
you try to meme something into existence based on some obscure technical
thing :).
> >But if it came to "mempool policy vs miner policy" then it is in the
> interest of both node operators and the network's health to change the
> mempool policy.
>
> Again, this seems like a slippery slope toward stuffing blocks full of data
> garbage rather than payments. You're basically saying miners should be in
> charge of bitcoin, and that non-mining nodes should have no mechanism by
> which to push back on miners. Am I misunderstanding?
>
Non-mining nodes push back on miners by validating transactions (and
their ability to do so is constrained by resource usage, which filtering
increases). This prevents miners from processing tranasctions that
violate the rules of the network.
But nodes have no ability to constrain miners' behavior if that behavior
is within the rules of the network -- except by coordinating to execute
a fork to change the consensus rules.
<snip>
> That is not what the data show. First, the opreturn filter results in a 99%
> reduction in confirmed nonstandard opreturns. Second, the dust filter
> itself was implemented as a result of spam attacks, and it has been
> perfectly effective since the moment it was implemented. Again, the purpose
> of spam filtration is not to eliminate 100% of spam. The purpose is to
> raise costs on spammers. Your email spam filter likely leaks a few spam
> emails once in a while, but I guarantee your reaction is not "it doesn't
> work; let's get rid of it".
>
Your "99%" number is silly. I could produce a hundred billion
transactions that violate some policy rule, send them to my local node
which will reject them, and then claim that the policy rule was
99.9999999% effective at filtering out such transactions. My point is
that there's no meaningful way to count "transactions that exist but are
neither propagated nor in blocks".
Mempool policy makes it inconvenient for people to use transactions that
violate the mempool policy. It may discourage them from building
protocols that require such transactions. But this discouragement has no
monetary value, which means that as soon as there is any economic
interest in producing such transactions, they will be produced and they
will wind up in blocks. This is what we see -- and it's why we are
talking about eliminating the data carrier filters and not about
eliminating, say, the MINIMALIF rule on pre-segwit transactions.
<snip>
--
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
--
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/aNnIvR5Naea8pXCe%40mail.wpsoftware.net.
--5eFL/aC/Ca8gVIfH
Content-Type: application/pgp-signature; name=signature.asc
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmjZyLgACgkQxYjWPOQb
l8EPYQf+OhhD3M1SUJr22VZ8Qrw/ej6yQWNNpBnwMGiuU8NM2CrDPnwVDW0OyIhV
jpazYlgX592pS+rsfi1MxD3kF8g7FSDING6LOhiTi1Wg/7i9I9OqloQ7/Lr995em
8TMSLVBUoWdw9TXbQr147Uf4g6jW4Wb+fdiMiXUIVedxn5MXJ8sR803DMiRtJtHA
59KCBF/e7aDIz6PBIbYO/CAeukEoFCkphWoph/TjOxQwWS8UjdQ2NPB+qIzKoyy9
Q8RgVthKLWvTSzXASWQC/lHKk7hY5damXuptqU8hIZPq/Jxj2SXUMbHMN+wbZIjq
K6I3VVLaHOvhZAVGP0jKTci2A7mawg==
=KH4A
-----END PGP SIGNATURE-----
--5eFL/aC/Ca8gVIfH--
|
