nomadshiba on Nostr: got help from llm to make this readable but here, let me know if you see any issues ...

got help from llm to make this readable but here, let me know if you see any issues in the story:

2 years ago, some people started to exploit taproot "contracts". they basically used OP_FALSE OP_IF to create unreachable code in the contracts and place none code, arbitrary data in it.

this is bad because a bitcoin node has two storage types, one is the blockchain, we all know how it works. other one is the state store (aka utxo set), state store holds the information of the current state of the network. so you can prune blocks, but you cant prune state data. since spammers store the data on fake contracts, they are stored in the state store, because a contract can be used at any time, you cant prune them. as you can imagine this made running a node harder. and if this keeps going it would make bitcoin less decentralized, and you cant suddenly run a node on your laptop.

fast forward 2 years, spammers took advantage of this exploit and started to spam the chain, making the UTXO set explode in size.

now the juicy part, bitcoin always had something we call mempool filters since the early days. they always got updates as the exploits like these appeared. and they did a great job, made it harder for spammers to do these things on the blockchain, and basically annoyed them so much and made them stop.

and as always 2 years ago, just before these new exploit got bigger, some of the devs were quick and created a PR for it on the core's repo updating filters to block this new exploit, like the many others before. but then bunch of spammer came and complained on the PR, and The Core said "this is controversial we are not merging this update".

but first lets not forget, these filters dont change the consensus rules, that would be dumb. all this filters do is filter spam txs from your node's mempool, but if a miner broadcasts a block with that tx in it you dont block it of course, that would split the blockchain. so its all about stopping the propagation of the tx in the network, basically making it harder for them to reach a miner. so they have to go to the miner directly in those cases, which would make their process more complex and expensive, eventually stopping them.

so now lets remember, we had a solution 2 years ago already, core didnt merge, but now this exploit harmed the network enough, made the utxo size explode in size. they wanted to find a solution to it, but their solution wasnt updating the filters to block these txs. no their solution was removing a filter on OP_RETURN.

what is OP_RETURN? well basically this stores the data on the block itself, not the state store. so nodes can prune them. which is better. and the default setting on the OP_RETURN filter was 83 bytes, so allowing only 83 bytes of data on the OP_RETURN.

so basically their solution is "remove the filtering limit on the OP_RETURN, so spammers use that instead of useing OP_FALSE OP_IF and storing on the utxo set (aka state store)".

even worse, they wanna remove the option from the settings page, so you cant even lower the limit yourself. they take away your say on the network.

but the argument is why are we allowing these on the base layer at all? we have working filters, why are we not applying them?

funny thing is 2 years ago their first argument to reject the initial filter update PR was "this topic is controversial". well "removing the OP_RETURN limit" is also controversial, but they pushed it anyway. so there is clearly something fishy happening, there is some clear incentive.

another funny thing is, these spammers are too aggressive that, they store the whole image on the chain, not just a hash to it, which would fit in the 83 bytes OP_RETURN. sha256 is 32bytes, that means 83 bytes is more than enough to prove something on chain. thats how many second layers use OP_RETURN. only reason you would wanna store the actual data on the chain would be that you wanna use the chain as CDN.

so worse part is removing OP_RETURN by force completely would mean that if you are running a node, your pc has to download these jpgs, and pass them around even if they dont end up on the block. they can fill up your whole mempool space leaving nothing for actual txs. so actual txs would hardly reach to the miners. not to mention this would eat up your bandwidth more. basically making running a node slightly harder.

so some might argue that, nodes already listen to miners, so what is the purpose of these filters on your node? well as i said it would stop them from eating up your bandwidth, but most importantly as i also said before, it would stop the propagation of these txs on the network making it harder to reach a miner, so they would have to go to the miners directly and this complicates things and adds cost. which stops the spammers.

if enough nodes have similar filters, they each can have a say what reaches to the miners. so if consensus is the static base law, mempool filters are the community.

another magical thing is, if a miner doesnt have similar filters to the rest of the network, when they find a block, it takes more time for that block to reach to the other nodes, which delays verification of their block, so if in that time another miner with similar filters to rest of the network finds a block, they win. so it also adds cost on the miner's side as well. so they have to charge these txs more when they reach to them directly. which also disincentivizes/annoys the spammers more.

lets say we did nothing, and bitcoin core didnt change too. what happens? well as these kinds of txs gets more popular on the bitcoin's base layer, it brings more people who are interested in doing these types of stuff into the ecosystem, which makes them add more things like these to bitcoin, which brings more people like them, which creates more things like these. its a downward spiral.

it becomes harder to run a node for various reasons, because keeping or making running a node possible on laptops or phones wouldn't be anyone's priority anymore. they care about other stuff, like monkey jpgs on the base layer, maximizing decentralization is not their goal.

being able to run a node on your laptop what makes bitcoin different, it runs on mine. if we lose that we have nothing left. base layer's priority suppose to be being decentralized, easy to participate in, easy to follow, and be a part of, nothing else should trump that.

which would let other layers to focus on being fast, private, cheap and more, because they can fallback to this secure base layer for security, in the worst case scenarios. if you start treating base layer like its a second layer, you would sacrifice its decentralization, trust, and security and everything would fall apart.

so it matters what node you run what filters you have. because running the wrong one, making the wrong group responsible for its future updates would also make running a node impossible.