"Nirvana fallacy (perfect-solution fallacy) - solutions to problems are rejected because they are not perfect."
Ordinal spammers, grifters, and apologists want you to believe filters don't "work". They will say this on repeat, while ignoring all evidence to the contrary. Because they're compromised, and arguing in bad faith for their own grift, or their employers.
Often they do not define what a "working filter" does, but when they finally get cornered into an answer they assert that a "working filter must stop all spam transactions from getting into all future blocks, forever. Otherwise it does not work!" That's right folks, there's no shades of grey here! Just black and white outcomes! Golly gee, these fallacies are fun!
This is what we call a false goalpost, which is related to the Nirvana Fallacy. It's a linguistic technique used by bad faith actors to distract away from the main point. The fact is, FILTERS WORK AND ARE WORKING NOW. Filters are being used by your Bitcoin node by default, and should be! (Lookup the dust limit!)
The grifters don't want these points heard, since they are valid, unlike their transactions in my nodes mempool. Rather, they want the discourse to focus on the extreme goal of complete censorship, as a way to shift focus away from the obvious.
Filters Work for your own nodes mempool. Saving you resources, your RAM, CPU power, bandwidth, and energy too. You not only save your resources by running filters (like permitbaremultisig=0). But, by locally running filters, you reduce your moral culpability, ethical and legal liability associated with this harmful spam.
Filters can also work by stalling propagation of spam transactions generally, if there's enough uptake by most node runners. Thereby, increasing the cost of this behavior in time for validation, and perhaps even by increasing the fee paid for validation of these grifting, infinitely reproducible, no-supply-cap, shitcoin-token, receipts-of-JPEG's.
Increasing the cost on this deviancy, in time, in money, socially, in any way, is desirable and has the effect of reducing the attacks long-term runway. And yes, it is an attack. Which can socially evolve and get worse over time. At the moment it is a benign cancer. But it can become malignant if we are not collectively careful. Unfortunately, Core devs & maintainers are naive, continue to play dumb and bury their heads in the sand on this issue. But that's a discussion for another time.
Furthermore, mass collective filtering of this spam by node runners can incentivize payments out of band, which works to identify mining pools who are directly collaborating with attackers. This also has the effect of increasing the time for validation of spam.
Hilariously, this was recently demonstrated by Rob Hamilton, the CEO of anchor watch. He attempted to showcase that the dust limit filter could be easily circumvented by a payment out-of-band to Luxor pool. Unfortunately, it took him and Luxor three days to figure out how to do this, thereby demonstrating the utility in forcing undesirable spam out-of-band. Adding friction in any way reduces the harm and runway of the attack. Clearly this friction was demonstrated by Luxor and Rob's inability to get their spam transaction confirmed in less than 432 blocks.
Once these bad faith mining pools are identified, like Luxor, they can be lobbied against by appealing to their miner clients to switch pools. Miners have an incentive to switch pools under these circumstances, since the out-of-band-payment payouts, as they are today, can’t be validated by miners. Rather, miners need to trust that payouts from out of band payments are being distributed fairly by the mining pool. Which the mining pool does not have an incentive to implement until they lose mining clients for being lazy or greedy. In any case, mining pools are getting a free ride as passive enablers of this unwanted spam-scam-grifting-useful-idiot-attacking behaviour.
“But what about muh mempool? Doesn’t this break fee estimation? Aren't you scared about these spooky third and forth order effects that have a low probability of occurring?”
Quite frankly, No. And that’s not my problem. I also believe this is low on the totem poll of negative potentialities involving this attack. Mempool fee estimation being more broken then it already is, is an outcome I’m very willing to accept for effective filter optionality at reasonable levels.
For instance, having an effective filter built into Core turned off by default is entirely reasonable, appropriate and warranted. Expecting people to disable their mempool entirely with Blocksonly=1 is like launching a nuke, when a scalpel is needed. It's entirely inappropriate, and potentially harmful. It's surprising that core devs are recommending this as THE option to enable.
Furthermore, Over 80% of respondents do not believe this spam activity belongs on Bitcoin. It’s reasonable to assume that this same group would run filters on their node if they were conscious of how to deploy this choice.
Sadly, most Bitcoin node runners don’t know what Bitcoin Core’s config file is, let alone how to use it to achieve MAXImum effective filtering of spam. Bitcoin Core devs & maintainers don’t seem eager to enable this choice either, even if off by default, for reasons that seem extremely close to the Nirvana Fallacy.
But there are still a few options for Bitcoin node runners to enable filters using the Bitcoin.conf file today.
The first one is a nuclear filter option. This option disables your mempool altogether, so you will not be relaying any unconfirmed transactions to other node peers, or be storing any in your RAM.
Be warned, this isn’t an advisable option if you run a lightning node or if you plan to broadcast your own onchain transactions. But you could simply turn your mempool on again when needing to do onchain transactions.
You can disable your mempool by typing “blocksonly=1” into your config file, then save the file and restart core, and your mempool will be disabled entirely, free of spam abuse. To turn your mempool back on, do the same thing but instead type and save “blockonly=0” and delete “blocksonly=1”.
With all that said, blocksonly=1 is a nuclear option that discriminates all transactions. Thus, non-spam economic transactions also suffer under this policy, same as spam transactions. But maybe as a protest some of you will want to use this option. Sipa (Peiter Wuille) is recommending it as a filter option, and as justification for not adding any new filters that are more targeted. Perhaps every node runner should listen to him and collectively shut off the mempool?
But for those who don’t want such an extremely broad filter, there are some more specific filters that eliminate spam from your mempool. To achieve this, it is highly recommended that you set
“permitbaremultisig=0” AND “datacarrier=0”
in your config file. These eliminate baremultisig transactions from being propogated to your peers mempools, as well as storage of baremultisig transactions in your RAM.
This is currently being used by the stamps scheme, a related ordinal scheme, to bloat the UTXO set beyond normal rates of growth. Thereby accelerating baseline pruned node and full node resource usage and requirements long term. Which sucks for those people who this will effect now and eventually, preventing them from running their own nodes.
As for Datacarrier=0, this eliminates OP_RETURN transactions from your mempool, which aren't as harmful, but are still being used by some of these BRC20 shitcoin-token schemes to grift and scam. It’s not unreasonable to filter these as an extra precaution, and to save your local compute resources.
You can go a step further socially and broadcast your preference for these filters by using saving “uacomment=stop the spam on your own node, set datacarrier equals 0 and permitbaremultisig equals 0” in your Bitcoin.conf file. This would then show up as a public message displayed by your node, readable by your node peers. You can set any custom message you like.
In conclusion, this false goalpost of: “you’ll never stop spam from getting into a block” is a) not the only goal and b) designed to distract away from the other goals that are immediate and obvious. Such as, personal node resource control, expression, compute savings, and the reduction of moral-legal liability associated with your nodes participation in distributing this unwanted spam content.
ie Sovereignty.
Which is the whole point of Bitcoin. You get to run the code you want, within consensus. Filtering is within consensus, and you already do it by default if you run Bitcoin Core with no modifications.
Filtering is your god given right as a Bitcoin node runner to turn on or off.
IT WORKS.
blocksonlywould be more effective at reducing bandwidth use.permitbaremultisig=0a go on my node. Thank you for the writeup.