This is a strawman. The filters make it more expensive, so people are putting the data in non-provably unspendable UTXOs. This is worse for the network then putting that data in provably unspendable outputs that can be pruned from the UTXO set.
Everyone saying filters "don't work" because spammers are just using op_return_bot to get around them? Yeah, op_return_bot has to charges double the regular fee rate or its bypass doesn't work reliably. This is a huge deterrent. The filters work.
Source: https://github.com/benthecarman/OP-RETURN-Bot/blob/master/app/controllers/InvoiceMonitor.scala
Discussion
Using unspendable utxos to store spam costs a couple of bucks more than using an op_return. The deterrent effect of raising the cost in this way outweighs the cost of storing unspendable utxos, in my opinion. True, unprunable spam is a worse kind, but you have to be quite motivated to do it thanks to its higher cost of production, and the result us much less spam overall. I think that's a good thing, it highlights the filters' deterrent effect. But if we remove that, the effect reverses: we get less "unprunable" spam (yay!), but at the cost of having way more prunable spam, and that seems worse to me.
Today using unspendable UTXOs costs *less* than OP_RETURN. That is your OP. Removing the mempool restrictions will reverse this.
For spam less than 150 bytes, here is the tier list:
Lowest cost option: unfiltered op_returns
Middle cost option: unspendable outputs
Highest cost option: private mempools
I support the filters because they push the cost of spam up the tier list
Would you support a change to set a consensus limit instead of just the mempool limit?
I support a soft fork to make the max op_return 0 bytes
I also support a soft fork to make a new witness field ("witness2?") where users are welcome to store up to 32 mb of spam per transaction
People who don't want to store this spam can just not run the new software. We learned from segwit that you can ensure backward compatibility by just not sharing the new witness data with people who don't flag their support for it.
I was confused by the technical aspects for a bit. Now I'm confused by the people who understand the technical details and oppose the change.
The core teams public relations on the subject has been terrible and I want to oppose just over that but emotional reprisal isn't a good plan.
So why make the most prunable data the most expensive place to put spam? Full archival nodes are all storing 4mb/10m either way. This reduces block size for pruned nodes assuming the arbitrary data people do go for it.
Please submit this as a BIP!
I think private mempools are a bigger threat than spam.
With wider adoption of stratumv2, wouldnt it be more likely that a public method of broadcasting transactions would come to market? For example, i could see projects broadcasting their non standard txs on nostr and miners having simple clients to grab and add those txs to their mempools. Could leaving datacarriersize alone help boost stratumv2 adoption in this way?
The ultimate solution would be to remove all standardness rules and use mempool for all txs.