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

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:

show full tweet

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.

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.