* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts]
@ 2025-09-26 13:26 Andrew Poelstra
0 siblings, 0 replies; only message 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] only message in thread
only message in thread, other threads:[~2025-09-26 14:16 UTC | newest]
Thread overview: (only message) (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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox