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
|
Delivery-date: Fri, 26 Sep 2025 07:16:26 -0700
Received: from mail-oo1-f56.google.com ([209.85.161.56])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBAABBL6A3LDAMGQERYS6ZGY@googlegroups.com>)
id 1v29FK-0002LV-70
for bitcoindev@gnusha.org; Fri, 26 Sep 2025 07:16:26 -0700
Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-62a98ee688csf421612eaf.1
for <bitcoindev@gnusha.org>; Fri, 26 Sep 2025 07:16:26 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1758896180; cv=pass;
d=google.com; s=arc-20240605;
b=Ic1B4Px0HEmsm6OMw94Z84/Qsu5SYL44mRnmwrNJUVlp4Bv+ItVrbdstDMfkCIxt++
i7OsWwjzuMpLodyDvDxcsz3yKN2tKTZ85GicTCvYqcfgnPcNQxB8oTslrLodtdkVYsF6
d3I/IThf0/L5Ok9BRT6KmUSAa4A5bSIOEPiv6hCU+p4SJeU1tQt76jmYRXRl5OX9pBcy
WHjL+UsOW+1xU70B/sCzt6yL//He8VpBQEiHEa9z2BfysPPWIXlmvs0Xcfx7Y7Pi/ezL
XfVSfQJSvymVby6kqhcDn1VTtEOMCvH1K5axAFw4hUpwFz8kNqBCexFqb6pc203GIzDm
W4sw==
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:content-disposition:mime-version
:message-id:subject:to:from:date:sender:dkim-signature;
bh=aQkvSJNmx70qGwe+1b/F32+MvEcIxw72GxzHrwbVp6Y=;
fh=TzD94EUpFS0C8NmiocW442ZdHcqenCuLk6XEG3XYVms=;
b=JiXoLATF0myeLYZBwJykc7fiRU0tWwtpWG/cNTFYy8qj6aQ1ZbEhJTAasAKJ+ElkDL
3Zqt1Qfpn38gNwlu9KgrgTEZLyxwp5Hatk63bToeAiC//T72VFNtVfOIBVxYeupM0/Io
o2nw/MARhAGaDtU+zijcvMA0bTVeeSvx0zY/etYJHoAgwGyKpBuOfT30fNGp9WpXntKn
DrG5yLZX8SYkmUialC3Upajc1dazvs8aPTuYIBYjeOmESLTWXpOAM58BeEqk6nAudbBm
Tp38Vv+A1WZSLBk5uaDYiR1/OnSSz2sUgwjVYwgSz5unHJ6DcLd0cLQRBssvIX9NeMsE
9kqA==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@mail.wpsoftware.net header.s=default header.b=berOptII;
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=1758896180; x=1759500980; 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:content-disposition:mime-version:message-id
:subject:to:from:date:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=aQkvSJNmx70qGwe+1b/F32+MvEcIxw72GxzHrwbVp6Y=;
b=f3+wBukBwi0K9mMLhVqsk5B7c4mJWrsu8/BLPQCL+sIKfR0LgEa5TSlWV78YjBfzgq
tyD9w2qFcyFoO42Lvd5q8gbWiXxVZ7s60IK55ArTdaBOJmMs90Yqby3cTgRVkKYkZNzb
w4V0oEPReBfG6tSsaFL9FKcwQrdcHP2jJD9QzqDFWfP/RSWp+/+w/iulquJps/+Ymmnp
3FNAW861fGtbNmuDVOPeZLePjxSGbSt6nltW1+yD3TVHcozR1Rcuoa/+VRhrVFcL3/S3
Sc5hQ9QIjcPHGDgkytD8donYiiC31AzXXjsXfdeRU01Hw870ePQeYn7FGIsEGojC8C9q
Dpyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1758896180; x=1759500980;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:content-disposition:mime-version:message-id
:subject:to:from:date:x-beenthere:x-gm-message-state:sender:from:to
:cc:subject:date:message-id:reply-to;
bh=aQkvSJNmx70qGwe+1b/F32+MvEcIxw72GxzHrwbVp6Y=;
b=LSYXmfYWU4eQia6dchEJejhQstPz8dvV3mnT+Mz2jf3mUH5HCKDwrduJLZ143OWMw+
N877Tmmq5FsoGRKJfD5rxOIfvUJFSRgvmXv/88mKm4MtBmfOvQh2qRDD/AKYHrIE2DSN
hIXYEIqyBmqPTrQupJkSeDbWthWFLQ6uXWYc4CUjUXhaQkgDVOQsR5ERQ0UUs/rD4xbM
BcrL/qipIKZ7T9dwfRDYhM03JiI+c9l2iz28M9+s5MWqIpxWN8P+XPTJnxMzPFvnUdWw
OwMXkOl5EYnNsSaQQiQOBrxYciocTtdmxh3Pkjr+jEshNqSK60TmL7LPdYZI2VYGFl9X
DkGg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWx/WY6RwtBCQdhmAYnnEyIbr5rXbtKGXDTM1Xs5H6bw9y7gdHMvhpn0q1VBT0jpA4G5jwptkZ9QxEJ@gnusha.org
X-Gm-Message-State: AOJu0Yx7wYUXK3U+l6TidN66SdUwo1FrLcaSgaMrepSbyBa2J8VxFevG
sKH2d5ZYkpemHiz7EW3z/RchDdp1grsCqW0dLAbhmXxrUPoktp6EDviW
X-Google-Smtp-Source: AGHT+IGq4txQmpr3Oa6gA5GevMUpVt0NO+D3CqMoZMxgLNp7uSJxbFy+zIscHpYUNIOsyowqPKUl5Q==
X-Received: by 2002:a05:6871:eb0c:b0:321:2521:5a5 with SMTP id 586e51a60fabf-35ebd6f4758mr3802989fac.3.1758896178904;
Fri, 26 Sep 2025 07:16:18 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd4bOoTHqj3Sb3HL+N4DLBePT4dJcrcrBYUvzKnQYbnZ6g=="
Received: by 2002:a05:6871:c687:b0:315:531e:fdba with SMTP id
586e51a60fabf-35eef9c998cls812372fac.1.-pod-prod-02-us; Fri, 26 Sep 2025
07:16:15 -0700 (PDT)
X-Received: by 2002:a05:6808:1454:b0:42c:5291:8ec with SMTP id 5614622812f47-43f4cc87ccdmr3254196b6e.18.1758896175279;
Fri, 26 Sep 2025 07:16:15 -0700 (PDT)
Received: by 2002:a05:6808:22c9:b0:438:241d:e72f with SMTP id 5614622812f47-43f5e412992msb6e;
Fri, 26 Sep 2025 06:26:41 -0700 (PDT)
X-Received: by 2002:a17:90a:d44c:b0:32b:d089:5c12 with SMTP id 98e67ed59e1d1-3342a2f5955mr9694177a91.33.1758893200863;
Fri, 26 Sep 2025 06:26:40 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1758893200; cv=none;
d=google.com; s=arc-20240605;
b=kpXioqRxOYr0wH8ZRsjtamoXXzN84pK3UE+y2+xc+CR+6yjfJSQUeU0F5Jr550RNyS
MtSkfQ1DEIdCfQeRGRCYATD3uMd+ClqcO4hnLZa6qNVzS7gPRthwg9WgRQnlqfvsx9mw
7kM2hDN0mnZ4/jzecjK8RYQTkxMJ1cD3oRT1+jFnhBl1/6HiJ8a2+ar54TXpz1ZN27dQ
qQ06IAdiiRJhxk5Lf8E6UkLBdrOLDCGmkSb9yyb20reRDFrSNGm0IRVAY7HaT/2xQLlF
gXw2RM50MunmJeY/QpADyuR3e8Tfr9bj2HLykR6HjFhO+q6n0WKrpW/O6e9YrOlJracg
H9bg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=content-disposition:mime-version:message-id:subject:to:from
:dkim-signature:date;
bh=gMnv7ql+lInBO9xiHlml8M9g3jV+NTkACUblYwJ9MDQ=;
fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=;
b=C16+xJcPnHE2ELw1ISV+rDC2rzMiaWf1ajKnstvgtOpb//Sm24F7Troc0D78o0dIXQ
ZopAje1qmpMAzP9Fy+D2kbgTRjHjzZhiwNcSBajDEfkY+894cPQUY+wZ0txDtynPyQJ4
uOvDXM+drUwxCPhkx+0Ot+waE66JfrL7BnOjSwXx1tyXqk6a35Yr4flHqSMNE0gX0slY
Qhxef0XKIIdtC0t5yhpZwZCCzECCJvHy2YrffABq8iCYH2AoE9969Z8KXjrFNoKdklDy
epJWwFFPR8fvGttIhP4AOZWJaYPzENqUnNuh7eV2EfmAQjjX+Lcz8upixQUQXeaV4yA8
ww8A==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@mail.wpsoftware.net header.s=default header.b=berOptII;
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 98e67ed59e1d1-3341bdc0274si354484a91.2.2025.09.26.06.26.40
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 26 Sep 2025 06:26:40 -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: Fri, 26 Sep 2025 13:26:37 +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: <aNaUjR7QTqWvtZLa@mail.wpsoftware.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="3Ss/Imfy4MTUcXSl"
Content-Disposition: inline
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=berOptII;
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 (/)
--3Ss/Imfy4MTUcXSl
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
(You sent this message to me personally but it looks like it was
intended for the list. I am replying to the list, which I hope is
okay.)
On Thu, Sep 25, 2025 at 07:37:04PM -0600, Chris Guida wrote:
>
> >The purpose of the mempool is to approximate the contents of blocks, both
> to help individual node operators (who would otherwise get large quantities
> of "surprise transactions" with every block)
>
> This is a new "purpose" for the mempool which did not exist prior to 2016
> when compact block relay was introduced. The original purpose for the
> mempool is, of course, to relay unconfirmed transactions to all mining
> nodes to increase the likelihood that transactions will be confirmed.
>
Yes, it is a "new purpose" introduced almost a decade ago to allow Bitcoin
to scale without unnecessarily causing load on nodes, which are essential
for the decentralization of the system but uncompensated by the network.
> >Any sort of filtering beyond that done by miners is contrary to this
> purpose of the mempool. This is a technical fact.
>
> Again, you appear to be ignoring the existence of things like the dust
> filter, transaction size filters, standardness limits on legacy inputs,
> etc. And also again, you appear to be implying that the mempool is *not*
> useful for relaying transactions to miners so they can be confirmed in
> blocks (and not just so that said blocks can propagate quickly).
>
If the dust filter, transaction size filters, standardness limits, etc.,
were being ignored by miners then they should be removed, yes. 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. 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.
> >It has nothing to do with "bitcoin's ethos", except its ethos as a
> consensus system, which directly contradicts your point.
>
> The mempool is not a consensus system, and noderunners are free to relay,
> or not relay, any transactions or blocks they like.
>
Yes, of course, but the goal of Bitcoin Core is not to let people do
"whatever they want" on the network. Core does not support "spy node"
operation, address indexing, or any number of things people have
requested but are unnecessary (or harmful) to the health of the network.
People can do whatever they want. This does not mean that Bitcoin Core
should actively support "whatever people want".
> Yes, in general things work more smoothly if all nodes have roughly the
> same view of the network, but allowing miners absolute control over the
> content of blocks in order to maximize their short-term fee revenue is a
> slippery slope toward a situation in which *only* data transactions are
> mined, rather than payments, and this would be fatal to a network that is
> supposed to be a payment system.
>
> Since there is no permanent way to disallow all data transactions in
> consensus, our only sustainable counterweight to this inevitable slide
> toward more and more short-term concerns by miners (at the expense of the
> network's long-term wellbeing) is mempool policy.
>
Unfortunately, this logic is akin to "We must do something. This is
something. Therefore, we must do this."
You are correct that, in a world where people are willing to pay more
for data publication than for transactions, Bitcoin will be overwhelmed
by data carriers unless it were possible to block data carriers. But
your proposed solution will not achieve this. To the contrary, it will
increase the cost of running a node for anybody who does it, and
increase the time it takes for blocks to propagate across the network,
both of which will have centralizing effects.
> When I say that disallowing filtering is not in keeping with bitcoin's
> ethos, I mean that bitcoin is a voluntary network where no one can coerce
> anyone else, and everyone is assumed to be following his or her own
> rational self-interest. Filtering dust is in the rational self-interest of
> a supermajority of nodes, because the alternative is massive utxoset bloat
> (and potentially node DoS attacks). Filtering data spam is no different; it
> has a very successful track record of helping to preserve bitcoin's
> usefulness as permissionless money, so it is beneficial to everyone.
>
Nodes filtering dust will, at best, prevent people from accidentally
broadcasting dust transactions. If somebody wants to do it, then they
will be able to, and any nodes that filter will be uselessly swimming
against the current.
If a meaningful number of blocks are produced that are full of dust
transactions, that filter should be removed (and perhaps some movement
to consensus-ban dust transactions will appear, which is a technically
much easier thing to accomplish).
> People are going to filter, because doing so is in their rational
> self-interest, so attempting to coerce people into relaying unconfirmed
> transactions that contain data (or designing systems on the assumption that
> everyone's mempools are always identical) is doomed to fail.
>
Nobody is "attempting to coerce people to relay transactions", any more than
you are "attempting to coerce" Core developers by posting polite messages on
the mailing list.
--
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/aNaUjR7QTqWvtZLa%40mail.wpsoftware.net.
--3Ss/Imfy4MTUcXSl
Content-Type: application/pgp-signature; name=signature.asc
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEkPnKPD7Je+ki35VexYjWPOQbl8EFAmjWlIsACgkQxYjWPOQb
l8FTNgf+LUpp3VieY6axwjpiU2Uw66PVMc9sHtdzgmSuWm7psnDoaNJWJaCW5CMv
/nwx7dk4dljzCjt504ia9Uoj7zKOoKKKvQFUObMRTPP5xOaJ49CeCL0OrYkhaaHV
TXiarJ2OoqlHI2gbrQpjUyrQsRNnZ3sjLkmyQiOk0JxGJZa0Qy+bw28uA5c01NZE
nEA3ISnxrkGtkJsX6Pm+rA5umtH63kfxs5cLqPjIFNqpSm00ivwsjwt4DbYUgZ7R
lxZZFc15r2oFoctdbS3E1i2/1G67haYejWvth2pJ5Pj3A+T15OxlIJLkKHTmbtny
eA6IPQfvuffc4/Aoqj7nw58LaTiHfg==
=L1TC
-----END PGP SIGNATURE-----
--3Ss/Imfy4MTUcXSl--
|
