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
What about libre relay?
There's theory and there's practicallity.
Theoretically Libre relay makes the filter useless.
Practically, this is either not fully known or understood by everyone... and this is why they are using out of band methods which hurts decentralization.
And by hurting decentralization, I mean only allowing well known miners and pools to capitalize on high fee paying non standard transactions, giving those miners an economic advantage... Theoretically.
The amount of extra money spam miners get is very small relative to their total profit. But the effect on spammers is massive in proportion to their total expenses, because fees are nearly their "only" expense. By doubling or tripling the effective costs of producing spam, there is an asymmetric positive effect: the spammers get relatively poorer much faster than the spam miners get relatively richer. This asymmetry makes the filters worth it imo.
That's what op_return_bot uses. They still have to charge extra.
Surprise, surprise. 👀
nevent1qqsga52844jhzzytpc5056h34wckklgv83z9e2puyqjk2c6eg4m4fuqpr9mhxue69uhhyetvv9ujuam9d3kx7unyv4ezumn9wsujvxcy
nostr:nprofile1qqs8fl79rnpsz5x00xmvkvtd8g2u7ve2k2dr3lkfadyy4v24r4k3s4spremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tc9vz57s 👀
Why do core devs want to make spam less expensive?
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.
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.
So maybe let's just leave things alone.
Quadrupple it!
nostr:npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s thank you for your awesome work 👍
Also I really enjoyed your Bitcoin vs Monero research.
