Personally I'm quite happy with empty blocks. I'd like fees to be higher, but I'm also never not gonna ninja in my 1 sat/vbyte tx, which I was quite proud of back when fees were actually kinda high a while back.

It started because people recently extrapolated what 100KB of contiguous data could be used for and having to decrypt that data to verify the transaction's validity would likely trigger anti-virus software labeling Core as "malicious content." Inscripting data is one thing because you'd have to reassemble the data using a certain specialized compiler. With 100KB contiguous, the bytes would be more or less in plain text, any image or video compiler could view the data natively. THAT is why people are getting upset. There is a very REAL chance that random strangers will send you, let's call it "bad stuff", that according to current law makes you a fed target. And outside that is disgusting to most people. This is why I never argued about the merits of OP_RETURN it's really just about property rights. My computer, my software, my rules. Want to make my node a CP magnet? No thanks, I'll run something else.

This PR linked solves the problem for every encoding attackers can invent unlike the treadmill of chasing new filters. It also works in a safe way for you, because all data is deniable always. A attacker can invent a new way around the filters and post CP as the first TX using that method. No way to defend it because the only way to close every hole is to stop accepting new transactions at all. Because of that filters cannot and will not ever protect you from CP being stored in your chain state. Step back and remember, the proposed filtering is authoritarian control over bitcoin transactions. Think of the children + we must do something, this is something, we must do this. Classic government marketing for new authoritarian bullshit.

GitHub

blockstorage: XOR blocksdir *.dat files by maflcko · Pull Request #28052 · bitcoin/bitcoin

Currently the *.dat files in the blocksdir store the data received from remote peers as-is. This may be problematic when a program other than Bitco...

Apparently no one is worried about the security budget…

I am aware of that PR, as of yet that is not in the build and is a theoretical fix to that on a deniability basis. Again though, bitcoin is a monetary network and the claim that the thing hindering a robust layer 2 is the size of the OP_RETURN field, is dubious at best. By my estimation therea not a single need for the datacarrier size to be over 100 bytea even in the most complex layer 2s I've seen. Now minting a shitcoin on bitcoin however takes much more data. I am less concerned with the "Think of the children" wrapping paper than the "Limiting arbitrary data is authoritarian" wrap. It is smuggling so many intended consequences I haven't even thought of the unintended ones.

I'm not. The cure is just higher value, IMO.