Just like the man in the original limerick, the error is thinking that if bad thing X is blocked, you must do bad thing Y instead

There once was a man on a mission

To end bitcoin's spam prohibition

And seeing the rule, "Not in the mempool,"

He used direct miner submission

There once was a man from Darjeeling

Who boarded a bus bound for Ealing

It said on the door, Don't spit on the floor

So he stood up and spat on the ceiling

Note: in the spam debate, Core fans say spammers blocked by the opreturn limit are "forced" to use private mempools instead

If the proposal itself is good then its source does not matter

Portland Hodl has proposed doing that and his proposal has received some discussion on one of the bitcoin mailing lists

If the other side thinks filters only "work" if they stop *all* spam then their definition is absurd. No filter in any context I'm aware of stops 100% of pollutants. Mempool filters have a clear statistically significant limiting effect. Removing them means they no longer think that effect is worth their cost. And that's where I disagree with them.

I agree that the filter did not prevent the ones that got mined from being mined

I do not think those are good grounds for doubting my hypothesis. I agree that fee bids are not posted randomly, in fact I think the stats clearly show that such bids favor 1sat per byte and higher.

If your hypothesis is that this effect is due to removing a range of bids all at once, then I think it is non-explanatory: if the filters have no effect, then fee bids ought to show up with similar frequently in the nearest values on either side of 1 sat per byte, because the range removed by each block is just as likely to leave transactions unmined on one side of that value as on the other.

But in fact fee bids do *not* show up with similar frequency in the nearest values on either side of 1 sat per byte. They favor 1 sat and higher. A better explanation is that something makes it harder for users to *set* feerates lower than 1 sat per byte; and in fact, most wallets don't *let* you do that, because they were designed with the filters in mind.

Most of the people who put spam in utxos use a protocol called Stamps. The Stamps protocol was created out of an explicit desire to put the data in the utxo set. See, for example, this quote from the cofounder: "The point of Stamps is to offer a method of encoding on-chain art that is highly resilient to tampering and goes a step further than Ordinals by being unprunable." source: https://thedefiant.io/news/nfts-and-web3/bitcoin-stamps-seek-to-improve-on-ordinals

Enlarging op_return to accommodate these people and make their data prunable seems pointless, as they have explicitly said they don't want their data to *be* prunable. If the point is to accommodate other, "less popular" protocols or one-off spammers, then the cure seems far worse than the disease: apart from Stamps, hardly anything uses output stuffing, so even if those other unpopular protocols *do* switch to op_return (which I doubt many will do), you'll get a very small benefit in that one respect at the expense of making low-effort spamming far easier for the masses.

thanks for saying so, I have now clarified it: https://github.com/supertestnet/list_of_technical_people_against_relaxing_the_op_return_filter

"Subsat summer" shows that the filters work. Here's a question for you: if the 1sat filter doesn't work, why is there a huge wall at the 1 sat mark? (This chart is for blocks 910047-911047 and is from x.com/mononautical) "No filters" would produce something like a normal distribution.

There is clearly something "special" about 1 sat per byte, as demonstrated conclusively by simple blockchain analysis. I think it is widely used in preference to the smaller values because the smaller values are *harder* to use, as you have to bypass the filters to use them.

op_return

> gun yo your head where would you put a spam transaction to do the least amount of harm?

In the spammer's brain -- if he stored the spam in his own memory neurons, and placed it nowhere else, it would do the least damage there

> low effort...spam is simply a software problem away

I'd like to keep it that way

I think many of them are attracted by the idea of paying a one-time cost for permanent file hosting, and I think that is more advantageous for spammers than it is for people trying to transfer their coins.

The reason blocks are permanent is *supposed to be* for assurance against counterfeits: users can check if the coins they receive are valid by tracing them back to their blocks-of-origin, and from there to the genesis block, and ensuring everything along the way follows the rules. Apart from giving us assurance against counterfeits, permanently storing every transaction only has negative effects, e.g. it is bad for user privacy, and it is a strain on your computer's resources.

So I think spammers have a *different* reason for using bitcoin than most bitcoiners do -- or at least a different reason than I use it. I use bitcoin for assurance against counterfeit money, and I see the permanent data storage as, in all other respects, a downside. But I think spammers use bitcoin for permanent data storage, and see the assurance against counterfeits part as irrelevant.

> while we can minimize spam in the op return it will just mean bloat elsewhere

I disagree because some low-effort spammers give up after failing to submit large spam via op_return, e.g. this guy:

https://x.com/AchimWar/status/1975406333584363932

It is not true that a would-be spammer's only choices are "put spam in op_return or put spam in more harmful places." They can also choose "don't put spam on the blockchain at all," and the above example shows that some would-be spammers (namely, low-effort ones) opt for the latter

Added! https://github.com/supertestnet/list_of_technical_people_against_relaxing_the_op_return_filter

He is a coder, but not a bitcoin coder (unless he is Satoshi, or part of Satoshi per the multiple-Satoshi theory)

Does he have a github or similar place where I can check his code or see if he sometimes reviews code? I don't want to include people who just "sound" like they could code; I want to include people who actually do it, or who review other people's code.

My list originally included Satoshi Nakamoto and Samson Mow. I removed Satoshi because the spam filter under discussion was created after he left, and I'm not sure how he would feel about it. I removed Samson Mow because I checked his github and saw that he does not appear to regularly write or review code for bitcoin (or bitcoin-adjecent) apps or protocols. As for Nick, he too does not appear to do that. He *influenced* the development of bitcoin, and might even be one of its creators, if the multiple-Satoshi theory is true, but I am not convinced that he is a contributor in the sense I am looking for.

This post contains my response to a collection of anti-filter arguments collected by Beeforbacon1 on twitter.

I've posted a screenshot of the arguments below and will reply to them one by one.

Source: https://x.com/beeforbacon1/status/1975501515021594825

> 1. Outdated policy - The 80-byte cap is ineffective today, users bypass it using Libre Relay, private relay networks, and direct miner channels. Loosening relay policy strengthens the free Bitcoin's open relay layer.

This argument commits the survivor fallacy. You only see the spam that bypasses the filters, so it's easy to "claim" every spammer gets around the filter. But you don't know how many spammers saw the filters and opted not to bypass them, or tried to bypass them but failed.

Moreover, the people who seek out and use spam-friendly tools like libre relay, op_return_bot, and private mempools are mostly "high-effort" spammers. They are likely to succeed. But the filters work great against low-effort spammers like this guy:

https://x.com/AchimWar/status/1975406333584363932

> Restrictive defaults push activity into private mempools

This is a false dichotomy. To say "do not put spam in public mempools" is not to say "put spam in private mempools instead." Spammers have another choice: do not put spam in *any* mempools

> fees, not arbitrary limits...[should] decide what gets relayed - strengthening the free market

Spam filters are selected by the free market whenever a user chooses to run free software containing them. It is not coercive to police your own mempool -- it belongs to *you,* not spammers.

Also, this argument is defeated by a simple "reductio ad absurdum:" if ejecting "spam" from your mempool was coercive, then ejecting *anything* from your mempool would be coercive too, as coercing is coercing regardless of the content -- it is a verb, not an adjective. But it would be absurd to object to ejections "in toto," as to eject "nothing" from your mempool would leave it open up to a variety of DoS attacks. Therefore ejecting is "sometimes" okay, and the question must be "which" content to eject. Crying "coercion" fails to do that.

> The cap just encourages worse hacks (like UTXOs, witness stuffing) that bloat the network more than OP_RETURN

This commits a similar false dichotomy as the second argument. To say "do not put spam in op_returns" is not to say "put spam in utxos and witnesses instead." The spammers have a third option: do not put spam in the blockchain at all.

> Miners already accept larger OP_RETURNs if paid. The default should reflect this reality

This argument has a faulty unstated premise: that all mempools should match whatever miners are doing. But in reality, bitcoin core's mempool policies are "intended" to be modified by end users to suit their own preferences, e.g. see https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp

Some users might "want" them to match the "average" of whatever miners are doing, which is fine if that's what you want, but other users want to use their mempools for something else: to assist with the relay of transactions they want to see more of and to hinder the relay of transactions they want to see less of. And a big reason why I oppose relaxing the op_return limit is because I want to see more of the latter.

> Simplification - Removing rarely-used config knobs (like datacarrier=0) avoids fragmentation of policies across nodes.

This config is not "rarely used." Over 20% of bitcoin users have switched to Knots precisely to keep using it. Moreover, "fragmentation of policies" is not a bad thing; as mentioned previously, bitcoin core's policy file is "intended" to be modified by end users to suit their preferences.

And a variety of policies is also healthy for the network in a similar manner to the concept of a "competitive federalism" -- just as the founders of the USA intended for each US state to compete with the other ones to adopt the best laws, various implementations of bitcoin can compete with one another to offer the best mempool policies. A one-size-fits-all solution hinders this.