* 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; 6+ 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] 6+ 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
2025-09-28 23:46 ` Andrew Poelstra
[not found] ` <CALL0pNF4b+rNYrgws0QY_LQP6QeVMEhLiOrFL4f-H3Ahf2ePDw@mail.gmail.com>
0 siblings, 2 replies; 6+ 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] 6+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts]
2025-09-26 21:50 ` Chris Guida
@ 2025-09-28 23:46 ` Andrew Poelstra
2025-09-29 13:11 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-09-29 13:41 ` /dev /fd0
[not found] ` <CALL0pNF4b+rNYrgws0QY_LQP6QeVMEhLiOrFL4f-H3Ahf2ePDw@mail.gmail.com>
1 sibling, 2 replies; 6+ messages in thread
From: Andrew Poelstra @ 2025-09-28 23:46 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 5348 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts]
2025-09-28 23:46 ` Andrew Poelstra
@ 2025-09-29 13:11 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-09-29 13:41 ` /dev /fd0
1 sibling, 0 replies; 6+ messages in thread
From: 'Russell O'Connor' via Bitcoin Development Mailing List @ 2025-09-29 13:11 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]
On Sun, Sep 28, 2025 at 8:07 PM Andrew Poelstra <apoelstra@wpsoftware•net>
wrote:
>
> 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.
I fully agree that this discouragement has little monetary value. As we
can see today, folks are bypassing the existing default mempool minfree
rate of 1sat/vbyte and still managing to fill up blocks with these sorts of
sub-1sat/vbyte transactions. This lets us measure the monetary cost of
bypassing default mempool filters. The cost is less than the cost savings
that such folks are achieving by their sub-1sat/vbyte transaction.
Eyeballing it, I see that the cost of bypassing default filters is
something less than 0.3sat/vbyte or so. Probably there was initially some
upfront cost, which is now being amortized.
I'm glad to hear that the default minfree rate is being lowered. I'd even
support eliminating the minfee entirely and instead relying on the max
mempool size alone.
Also, as Andrew touched on, one valuable role of filters is to try and
filter out third-party malleable transactions to the extent reasonably
possible, or at least filter out their non-canonical / non-min-cost forms.
That is valuable because those sorts of transactions are at great risk of
never appearing in blocks.
--
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/CAMZUoKkU%2BYnA_HorhGCwQqmLsnPZ8cqf1MJ_U3CE8j1%2BNgJV4w%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 2860 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts]
2025-09-28 23:46 ` Andrew Poelstra
2025-09-29 13:11 ` 'Russell O'Connor' via Bitcoin Development Mailing List
@ 2025-09-29 13:41 ` /dev /fd0
1 sibling, 0 replies; 6+ messages in thread
From: /dev /fd0 @ 2025-09-29 13:41 UTC (permalink / raw)
To: Andrew Poelstra; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 6610 bytes --]
Hi Andrew,
> 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.
Have you tested compact blocks relay with default
`blockreconstructionextratxn` in knots v29.1?
/dev/fd0
floppy disk guy
On Mon, Sep 29, 2025, 5:37 AM Andrew Poelstra <apoelstra@wpsoftware•net>
wrote:
> 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
> .
>
>
--
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/CALiT-ZqxbLmRDuWMqubYDeSvawSg0xgQ8khet%2Bw6YTJKy7aqeQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8543 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts]
[not found] ` <CALL0pNF4b+rNYrgws0QY_LQP6QeVMEhLiOrFL4f-H3Ahf2ePDw@mail.gmail.com>
@ 2025-09-29 15:24 ` Lőrinc
0 siblings, 0 replies; 6+ messages in thread
From: Lőrinc @ 2025-09-29 15:24 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 4177 bytes --]
This is a slightly friendlier version of a previous reply I sent to Chris
already:
--------
> The tripling of the utxoset within a couple of years has raised the
minimum cost of joining the network from ~$150 to ~$250
I will be short: we want blocks to be full, blockchains are meant to grow,
and even cheap nodes were more expensive in the past than what we can have
now (which are also a lot more performant).
I bought a node in 2021 for ~$330 (which is *~$400* inflation adjusted) and
it struggled with 700k blocks for weeks:
https://x.com/L0RINC/status/1968189583180579188
If you're into storing the whole chain for some reason, you can have the
same for *~$170* now and it will finish IBD in less than 1 day, depending
on your internet speed (with average global speed just downloading it takes
~16 hours), see https://x.com/L0RINC/status/1967679285168386135.
But you can also get a very good fully validating pruned node for *$111*
(e.g. https://gist.github.com/l0rinc/5a44ffa174857bc9c680a8e4bfc40a88),
which can likely finish an IBD in ~2-3 days.
You can even buy one for *$99*, but that would indeed be quite slow, but
even that would likely finish IBD in a week. You can go even cheaper with
second-hand hardware. But I'm not sure why we would want to go lower than
the price of a single night in a hotel...
> core devs have done nothing to prevent it from happening again
Core devs progressively made the latest version 250% faster than v23
https://x.com/L0RINC/status/1970918510248575358.
And we still have other unmerged optimizations, so the situation is
expected to be even better in upcoming releases. On my laptop our unmerged
changes can fully reindex in ~2 hours. And with a SwiftSync prototype I
have even done a reindex-chainstate on a battery-powered cheap rpi5 (+
monitoring over wifi) in ~3:14 hours (pi on a pi - and the batteries were
still 70% full): https://x.com/L0RINC/status/1972062557835088347.
The situation has never been better, you can now do IBD from batteries!
> core devs should listen to their users
Twitter is not a representative sample (and neither are you).
In the free market, participants produce stuff and the usage is the
feedback, not the online complaining.
> 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.
I also retested an old Raspberry Pi 4b with 8gb: IBD with v30 finished in *71h
36m 44s (<3 days) *until ~916k blocks with default dbcache.
With a 5GB dbcache it would likely be even faster, I just wanted to see the
worst case.
> Reducing data spam (or utxoset workarounds like libbitcoin) are what we
should be focusing on to increase participation in the node network.
I don't see how *spent + unspent* can be smaller than just the unspent set.
> but practically everyone with a low-resource node noticed extreme
increases in IBD times due to spam
It's not the "spam", that's very cheap to validate. They just likely forgot
to update the node (leaving the assumevalid height early and they're doing
too many useless script validations) or are writing on cheap SD cards with
10MB/s rate or are doing IBD over TOR or are leaving the dbcache size at
default or increasing it to the total memory size and are constantly
swapping, or have enabled all optional indexes, etc.
I agree these should be better documented, it's why
https://github.com/bitcoin/bitcoin/pull/33336 and
https://github.com/bitcoin/bitcoin/pull/33333 were opened: if only you used
all this anger to educate people and help, instead of blaming the firetruck
for the fire...
> The purpose is to raise costs on spammers
Why do you focus on hating people who disagree with you, even when that
hurts honest participants?
--
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/CALL0pNFxsRCF00CN3YwSZOnoATB%3DzAdZQXpKvy_4oAOjRx40%3DA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5178 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-09-29 15:30 UTC | newest]
Thread overview: 6+ 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
2025-09-28 23:46 ` Andrew Poelstra
2025-09-29 13:11 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-09-29 13:41 ` /dev /fd0
[not found] ` <CALL0pNF4b+rNYrgws0QY_LQP6QeVMEhLiOrFL4f-H3Ahf2ePDw@mail.gmail.com>
2025-09-29 15:24 ` Lőrinc
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox