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.

Reply to this note

Please Login to reply.

Discussion

I’m more anti Luke jr. than I’m anti filter so I appreciate this thread and don’t have any strong arguments except I think it’s a bit of a cop out to say that spam doesn’t belong on bitcoin and expect that spammers will respect that. Spammers target bitcoin because it is the most meaningful project. If you don’t have a solution for high effort spam please realize that today’s high effort spam will be tomorrow’s low effort spam. It’s all getting much easier.

Overall, I think the rhetoric and the fear mongering about csam is a disgrace and it is one argument that seems to only come from the Luke jr side who thus far have produced zero reasons for me to trust running any of their software,listen to anything they have to say and indeed believe that they may not be making any arguments based on sound reasoning.

You completely ignore it being a POSSIBLE attack vector. Removing the filter provide no benefit to money.

It reduces the centralizing effects of submitting direct to miners and it makes it possible to not push spam to utxo. Both of these things are better for bitcoin and therefore support the monetary aspects of the chain.

Yes if spammers can use op_return instead of direct submission to miners, it helps to prevent mining centralisation from getting worse. However, the only pool I could find that publicly offers this service is Mara with slipstream. Doesn’t it seem a bit premature to remove op_return limits with the intent of reducing mining centralisation by making a service that a pool with only 5% of the hash rate offers, obsolete? I understand that other pools may implement this service later down the line, but that means this change does not reduce mining centralisation from its current levels, it only helps to prevent it getting worse. We can agree mining centralisation is a problem today, so wouldn’t it make more sense to support solutions that actually reduce mining centralisation like Ocean and DATUM instead of pushing contentious changes that only help prevent this issue from getting worse?

Removing op_return does give spammers a less technically harmful alternative solution for uploading spam, but are many spammers actually going to use it if the op_return solution is 4x more expensive? I hear the “fees are the filter” argument a lot , but this contradicts the point that with the removal of op_return spammers can spam in a less harmful way because wouldn’t they choose the cheaper alternative (witness data)? We both agree that inscriptions are bad for bitcoin and so isn’t the most logical choice to provide a solution to this bug, such as the one knots has already implemented (inscriptions filtering at the mempool level) and the one core refused to implement in 2023.

Perhaps mara is not dominate because the service they offer is not in demand currently. I think core would argue against things that create the game theory conditions for more centralizations. Core has been discussing these changes for years.

Datum won’t fix this specific issue.

Everything is a technical difficult thing until it isn’t. Software makes all types of spam easier over time.

Filtering inscriptions at the mempool level isn’t a bug fix. It’s just more filters and is fraught with cat and mouse games, arms race, and major issues false positives. I would rather we deal with spam vs have non spam transactions getting censored my overzealous filtering.

One of the reasons core say they are making this change is to address mining centralisation by disincentivising direct submission services. Funnily enough Datum does fix this. If a large majority of pools use Datum then it’s the individual miner responsible for the block template construction, not the pool. This then makes it significantly harder to directly submit your transaction and see it included as there is much more variation in who is mining the block. The issue with mining centralisation today is that there are a small number of pools with majority of the hash power responsible for block template construction. This can lead to out of band transactions becoming more centralising for the large pools. But why not support a solution that gives the block template construction back to the hashers which would solve this entire block template construction centralisation issue?

If Mara’s slipstream is not in demand why even rush to make this change. What you’re saying is, it’s not in demand now but we guess it will in demand in the future. It seems very premature. There is currently a lot of demand for spam on bitcoin, so it’s interesting that this service is not also in demand.

The cat and mouse game is always worth playing if you don’t want to facilitate spam on bitcoin. It signals a hostility towards spammers, which will push a large majority of spammers away (it pushed vitalik buterin away in 2014), because the only way to spam is to pioneer a new method which is beyond the ability of a majority of people, and even if this new method can be made easier for regular people, it will be able to be filtered out by nodes as well. If bitcoin is very unchanging, there are only so many possible ways spammers can hack spam in. And it’s a game that the anti-spammers will win because filters more dynamic and easier to implement than the creation of new methods of spam.

I’m interested to understand how filters facilitate censorship. Currently 99% of all nodes have filters, does that mean bitcoin today and since it’s creation has been a censoring platform? Also, filters do not filter out monetary transactions, for example, even if on knots you set the datacarriersize=0 (which is the filter relevant to op_return), all native monetary transaction will not be filtered. It’s a similar story with filtering inscriptions as inscriptions have to use a pattern that is identifiable.

What do you propose when you say “I’d rather we deal with spam” because doesn’t opening the op_return limits actively facilitate spam?

Datum doesn’t solve the issue of miners wanting to mine higher fee blocks. You are fighting against greed and that rarely works out. All you need is one pool attracting all the miners who want maximum revenue and suddenly the balance tips and these miners become the high margin game in town. Over time they win and the datum miners excluding spam lose.

There are methods to hide spam in inscriptions that filters cannot stop without censoring non spam transactions. I would rather deal with some spam than deal with a system that is now suddenly no longer censorship resistant. This is a fundamental philosophical issue. Luke jr is driven by an insane desire to please the state. I don’t care what the state wants I want freedom.

The current filters at issue don’t facilitate censorship because they aren’t actually doing much. People who want to get shit on chain have lots of aveneues. The filters luke is proposing to weed out inscriptions will promote censorship because no one can guarantee that they won’t be censoring transactions that are in fact valid monetary use cases. This becomes a governance issue and turns this whole system into a shitcoin dao.

We have rules about what a valid transaction is. A mempool policy should not override that.

In the end this all doesn’t matter much but it has been illustrative as to how many bitcoiners are retarded followers of someone like Luke Jr.

Miners wanting higher fee blocks is not an issue and is in fact important for the security of the network as the block subsidy decreases and the industry becomes more competitive. The issue is that a very small number of entities have control over block template construction. How does Datum fix this? It allows for any hasher not just the pools to be in charge of block template construction. This of course addresses block template construction centralisation as now you have millions of individual hashers responsible for what goes into a block. This means it will be extremely impractical to go direct to a miner as even the largest miner Mara only has ~5% of the hash rate, meaning it would/could take a long time before your submission was mined.

“All you need is one pool attracting all the miners who want maximum revenue”. Wouldn’t this large pool also attract all the miners that don’t include spam as well and therefore the rewards would be distributed among miners who do and don’t mine spam? We must assume miners will always prioritise profit and so the nodes need to disincentivise miners from including spam. How do the nodes do this? If a majority of nodes filter large op_return transactions (over 80 bytes) the block filled with large op_return will propagate slower and the risk of that block going stale is higher. This disincentivises miners from mining spam filled blocks as they may lose the whole block entirely. This is a realistic possibility and why Mara charges 2x for slipstream.

“The current filters at issue don’t facilitate censorship because they aren’t actually doing much.”. If this is the case, why does removing them improve the network in anyway if they don’t do much? Why not just leave them if they aren’t doing anything? It’s funny that you say they don’t do much when 99% of all op_return transactions since the addition of op_return have been under 80 bytes meaning they are extremely effective at what they were designed to do. Just because they can be bypassed by a determined spammer doesn’t mean they don’t do anything. The fact they have to be bypassed means they do their job very well.

The current filters issue relates to datacarriersize. This DOES NOT filter regular transactions because regular transactions do not use op_return. Op_return was designed for arbitrary data and so this the filter of 42/80 bytes related to how much arbitrary data will be relayed. Opening op_return to 100kb signals that the storage and sending of arbitrary data is a native feature of bitcoin, basically meaning that spam is accepted. I assume we both want bitcoin to be a monetary only protocol, the changes to op_return take bitcoin in the opposite direction.

“We have rules about what a valid transaction is. A mempool policy should not override that. “. The rules regard to consensus which are the rules we all agree on and hence will be looser. When I run a node, I have my own mempool that is not shared with anyone. Should I be able to decide what data my own hardware stores in plain text in RAM, and relays?

Mempool policy does not ‘override’ a valid transaction because everything in a mempool must be adhering to consensus rules otherwise nodes won’t accept it.

Lucid argument without any mention of CSAM. Choose your own policy. Fantastic.

However the “competitive federalism” analogy, while aspirational, breaks down under the actual mechanics of Bitcoin tx relaying between nodes/miners. There’s one consensus chain which can be dictated by a MINORITY of LOOSER node policies.

Unfortunately for the idealists: this is a one-way (or at least asymmetric) valve. It is what it is.

nostr:nevent1qqs9umtsd55fx860lg8g0gnpjvxuve24r8a7fr739lz634rdqhja65qpndmhxue69uhkummn9ekx7mp0y5erqamnwvaz7tmwdaehgu3wd3skuep0y5erqffjxpshvct5v9ez2v3swaehxw309ahx7um5wgh8w6twv5hj2v3sy5erqctkv96xzu39xgc8wumn8ghj7ur4wfcxcetjv4kxz7fwvdhk6te9xgc8wumn8ghj7un9d3shjtnyv9kh2uewd9hj7ffjxpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uumhnam

I guess Friday is paedo porn day for Bitcoin courtesy of Bitcoin Core v30.

This was an incredibly smart and helpful read, Super Testnet. Thank you! (Also, I loved your interview on the Bitcoin Takeover podcast!) 🙏

Oh I have a question… would a higher percentage of nodes running filters be at all effective at raising the fee price of larger non-monetary arbitrary data transactions? Because even if it makes their transaction prices go up just a little bit higher (hopefully a lot higher for bigger data “dumps”) I’d be happy to make them pay more, in sats, as well as in aggravation.

These aren't arguments from core, they are smokescreen. The real conflict is over raw will to power, formerly held by true cypherpunks, but (thanks to "dev support" funds) atttacted grifters. Power over the central organization knowm as "bitcoin core" is presently wielded by captured agents who likely are hiding their true motivations.