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, 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".