The word "work" is doing a lot of heavy lifting here. You haven't shown that cleaning your mempool is desirable (it's not). Here's a better syllogism: 1. If a configuration option is ineffective at keeping data off the blockchain, it should be removed. 2. OP_RETURN limit is ineffective at keeping data off the blockchain. 3. OP_RETURN limit should be removed. QED

A clean mempool is desirable because it keeps your disk space ready for better uses than storing other people's spam Regarding your syllogism, your first premise fails of configuration options have any other purpose beyond keeping data off the blockchain. And they do: the primary purpose of mempool policy, for example, is to police your mempool, not your blockchain.

The teem "ineffective" in your first premise provides a clue to its faultiness: it embeds a negative into a key term, and when this term is unpacked, we discover that you are really assuming a universal negative: namely, that there is no other purpose beyond the one you identify as ineffective. Proving a universal negative is, of course, really difficult, and a semester of philosophy might teach you this.

Do you really prioritize fleeting ram use over permanent disk storage? That is a silly priority to have.

You will store the "spam" anyway when it gets mined. But you already know that. You will not stop others from using Bitcoin the way they want. Enjoy your pure mempool.

Ram is more precious than disk space, that's why 1tb of ram costs way more than 1tb of disk I prioritize efficient use of the scarcer resource

Blocks are persisted to disk, which is abundant The mempool is stored in ram, which is scarce Therefore spam is more harmful in the mempool than in the blockchain

Interesting, I use the 300MB default maxmempool and have never been harmed by spam. Sounds like FUD to me.

I prioritize eternity over fleeting.

It depends on what you find harmful In this post, Chris Guida outlines why he thinks spam is particularly harmful:

X (formerly Twitter)

Chris Guida | ⚡🪢 BIP110 (@cguida6) on X

Several core supporters have pointed me to Pieter Wuille’s recent StackExchange post[0] explaining core’s rationale for raising the default opr...

I've read this thread. It's predicated on a nonsensical statement from Greg Maxwell: "Demand for cheap highly-replicated perpetual storage is unbounded." "Cheap" and "unbounded demand" are opposites, lol. This is fear-mongering about Bitcoin becoming a database. If it's so valuable as a database, and you need to pay for said data storage using Bitcoin, how is that bad for Bitcoin? Sounds bullish to me.

You clearly don't understand cost and the multidimensional status of things. There's more than just one kind of limitation.

What about the consequences of slower verification of blocks for the whole network of nodes, due to Knots nodes not being able to start validation because they dismissed economically relevant valid transactions? Longer validation can cause competing blocks more likely. The fee estimatiom problem is also a well-known predictable effect of purging mempools this way. Yet another serious issue is to burden all nodes with substantially more validation _for ever_ with inscriptions in pubkeys. In contrast, op_return can be ignored in validation. I think these side effects dwarf your concerns about temporary RAM benefits. In addition, the CSAM arguments have existed for long as well and, though not a lawyer and all, but Knots nodes will store these as well and relay them as valid blocks to other nodes, so there is no benefit I see here either. I am almost sure you knew these arguments already. Failing to steelman the other side is a mistake. Do you want to get closer to truth or justify an outcome? The only "moral" of bitcoin is economic incentives, strictly speaking. People will argue on subjective morals and semantics for ever. What we strive to achieve with money is as close to objectiveness as possible though. Wishful thinking with ignorance towards reality caused the fiat system in the first place. Camouflaging this with morality and a veneer of certainty instead of focusing on error-correction is just an appeal to authority and a path leading back to a fiat.

If you store "spam" in RAM until it gets mined you avoid having to redownload and cryptographically verify the "spam" tx once it gets mined into a block or it is broadcasted to you by another node. That saves both bandwidth for downloading and CPU for verifying. I would not agree that disk space is abundant. You can get by with just 300MB RAM for an unfiltered Mempool and don't have to upgrade RAM however many noderunners will soon have to upgrade from a 1TB SSD to a 2TB one which is a cost factor and also implies manual effort and downtime.

> If you store "spam" in RAM until it gets mined you avoid having to redownload and cryptographically verify the "spam" tx once it gets mined into a block Sure, but in the meantime, your memory is free for uses better than storing and relaying spam. I am reminded of the man who said he wouldn't shave because it just grows back again. That's fine as a personal preference, but the alternative tradeoff makes excellent technical sense: at the cost of downloading a few kilobytes later, you reduce the spam in your mempool and provide miners with a monetary incentive to not make spammy blocks (that incentive being faster block propagation). > I would not agree that disk space is abundant. You can get by with just 300MB RAM for an unfiltered Mempool and don't have to upgrade RAM however many noderunners will soon have to upgrade from a 1TB SSD to a 2TB one which is a cost factor and also implies manual effort and downtime. Interesting use of the phrase "you can get by." You can certainly get by without upgrading your mempool, but you can also get by without upgrading your hard drive, by pruning.

> What about the consequences of slower verification of blocks for the whole network of nodes Only blocks containing spam are delayed. This is a desirable outcome because it provides a monetary incentivize for miners to ignore spam. > The fee estimatiom problem is also a well-known predictable effect of purging mempools this way It is not a problem because nodes don't look at the mempool when estimating fees. > Yet another serious issue is to burden all nodes with substantially more validation _for ever_ with inscriptions in pubkeys. In contrast, op_return can be ignored in validation. I personally think the "cure" (raising op_return to 100kb) is worse than the disease. Very few protocols store data in pubkeys. The ones that do are unpopular and rarely used. Storing arbitrary data on the blockchain is a significant abuse of the blockchain, and relaxing op_return will, I suspect, invite even more of it, thus doing more harm than the comparatively small problem it supposedly fixes.