* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts]
@ 2025-09-26 13:26 Andrew Poelstra
2025-09-26 21:50 ` Chris Guida
0 siblings, 1 reply; 2+ messages in thread
From: Andrew Poelstra @ 2025-09-26 13:26 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 5880 bytes --]
(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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts]
2025-09-26 13:26 [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts] Andrew Poelstra
@ 2025-09-26 21:50 ` Chris Guida
0 siblings, 0 replies; 2+ messages in thread
From: Chris Guida @ 2025-09-26 21:50 UTC (permalink / raw)
To: Andrew Poelstra; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 14843 bytes --]
Hi Andrew -
>(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.)
Haha yes, indeed! Thank you sir 🙏
I don't suppose it's worth it to try to "reply all" on my previous email to
re-attach this to the previous thread...
>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.
>which are essential for the decentralization of the system but
uncompensated by the network.
Yes, and this is exactly the problem with data spam, and also the problem
with bitcoin core's recent shift.
The tripling of the utxoset within a couple of years has raised the minimum
cost of joining the network from ~$150 to ~$250, which is permanent damage
that may never be fixed, and worse, core devs have done nothing to prevent
it from happening again (raising the opreturn limit does nothing to prevent
brc20 or similar schemes).
Data spam pays an upfront fee, then enjoys bulletproof integrity and
availability guarantees for the rest of eternity. A finite quantity (the
upfront fee) divided by an infinite quantity (the amount of time the data
is hosted) is zero. This is why payment txs can never fairly compete with
data txs.
In addition, the fee does not actually go to the noderunners hosting the
data; it only goes to the miner who mines the tx. So data txs are an
unwanted and unnecessary burden on noderunners, which means they worsen the
cost/benefit analysis of running a node, leading to a smaller node network.
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).
You appear to be making the claim that a merchant will have a better time
running a node if he doesn't filter transactions than if he does. The last
two years have proven this wrong. The primary culprit for making life
difficult for merchant noderunners is data spam. A merchant's node will
still work just fine even if block reconstruction times are quite long. A
Lightning implementation such as CLN will not even notice the difference
between a 1-second block propagation and a 10-second one. It just doesn't
matter.
Conversely, the spam attacks from 2023-4 have directly led to increases in
IBD times that are so extreme that the most popular merchant node hardware
(the RPi 4B 4GB) can no longer sync the chain in under a month, and the
next cheapest hardware that can do so is much more expensive. Reducing data
spam (or utxoset workarounds like libbitcoin) are what we should be
focusing on to increase participation in the node network. Pro-spam
measures like ripping out the opreturn limit only make the problem worse,
by fueling demand for shitcoining on-chain.
>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...
>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?
>People can do whatever they want. This does not mean that Bitcoin Core
should actively support "whatever people want".
Sure, but see the prior discussion, where you acknowledged that if bitcoin
core does not make running bitcoin core a good UX for its users, then very
few people will run bitcoin core nodes. So core devs need to strike a
balance between disallowing popular user behaviors and discouraging
noderunners from participating at all.
>Unfortunately, this logic is akin to "We must do something. This is
something. Therefore, we must do this."
No, that's not what I'm saying. I'm saying we can't sustainably fight spam
in consensus, and the only other enforcement mechanism besides consensus is
what we relay. It's a much weaker enforcement mechanism, but it's much
better suited to countering rapidly evolving threats than consensus, and it
has historically been very effective at countering data spam. I can think
of no other mechanisms besides consensus and standardness to bias the
bitcoin network away from data and toward payments, can you?
>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.
This claim is incredibly dubious. Again, there is incontrovertible
historical data showing that data spam has been directly responsible for
significantly increasing costs on noderunners. Slower block propagation via
filters has not produced anywhere near the same effect. I'm actually not
even sure what the mechanism for such increased costs would be; can you
elaborate on how this works? Anyway no one I know has noticed an increased
cost from slow block propagation, but practically everyone with a
low-resource node noticed extreme increases in IBD times due to spam.
Filtering inscriptions as soon as they started being exploited would have
easily prevented this.
>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.
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".
>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).
Right, but this is unlikely because of the dust filter. Likewise for
opreturn.
>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.
Sure, that's why I said "or designing systems on the assumption that
everyone's mempools are always identical".
Best,
--Chris
On Fri, Sep 26, 2025 at 8:16 AM Andrew Poelstra <apoelstra@wpsoftware•net>
wrote:
> (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
> .
>
--
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/CAAANnUz3V-ciTB1%2B9tUz8yByhd66UpyPJTZEQFrPRMjLXZfdwQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 17246 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-09-26 22:07 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-09-26 13:26 [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts] Andrew Poelstra
2025-09-26 21:50 ` Chris Guida
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox