With that history in mind, removing limits on OP_RETURN standardness size is pointless. Relaxing OP_RETURN size limits without dealing with the inscriptions exploit means no one will use this for anything besides attacking the network with the worst possible data. There's little to no incentive to use OP_RETURN for data storage when using the 'inscriptions' exploit costs 4x less in transactions. What's the point of having a "standard" way to store arbitrary data if the exploit method is 4x cheaper? And the nonstandard version of the exploit allows 4x the data?
Further, the inscriptions exploit currently requires chunking the data between PUSH opcodes, meaning an on-disk analysis doesn't actually directly reveal the underlying data the injector intended. I can still run something like "photorec" on my system and not have to sift through thousands of 'inscriptions'. Removing the size limit on OP_RETURN breaks this happenstance obfuscation that has saved us to-date. After this change, when data is recovered from a full node system, whatever some anonymous person decided to stuff into an OP_RETURN will be serialized in plaintext directly on disk. For the low price of a few sats per byte, an attacker can now directly poison the storage of every full node runner.
If you can't imagine the harm this will do to the ecosystem, let me paint some pictures for you:
First, there's the obvious. Everyone running a node will now be guaranteed to "posses and distribute" content that is likely illegal in their jurisdiction. Not only are you storing this as a full node runner, you're serving it to others. Hooray. /s
Next, there's less obvious abuses. For example, let's say I want to distribute malware. Well, might as well just store it in an OP_RETURN. Then, any time I compromise a system with a Bitcoin node I know my malware is directly on their system in a mostly predetermined spot already and I don't even need to retrieve it from elsewhere! And, even better, my malware can use the Bitcoin P2P network itself to distribute itself. Just find a willing full node, grab the block it's in. Thanks for the boost, node runners!
Worse, in order to actually participate in the network, everyone MUST download all of this data from others (who must host it for you), process it, and generally must host it for others to do the same. The network can't survive with 100% pruned nodes. I think too many users nowadays don't understand that running a full node is the ONLY way to actually participate in Bitcoin.
It's bad enough that chunked partly-obfuscated things exist on the systems of full node runners today. It'll be even worse if that's unrestricted with the removal of such limits.
As I said in my Github comment: This is far more than a small technical change. This is a fundamental change to the nature of what the Bitcoin network itself is in its entirety. Ten years ago, developers of the reference implementation knew this, and acted in the best interest of Bitcoin itself. Today, too many developers don't understand this duty.
That may sound like hyperbole, but it really isn't. If this change is merged into Bitcoin Core, and Bitcoin Core then continues to be the reference implementation... Bitcoin as we know it changes forever in the most fundamental way imaginable: The reference implementation explicitly turning the Bitcoin network into an arbitrary data storage system, instead of evolving it as a decentralized currency.
That's not Bitcoin anymore, and we might as well give up on Bitcoin ever being a thing if this is the path chosen.
There are very few paths that lead to a worthless Bitcoin, and this is probably in the top 3 worst options.
I can't understate this. It's one thing to refuse to act when faced with an attack/exploit/etc. That takes actual courage and conviction to do what's right for the ecosystem... and I _almost_ can't fault the current batch of devs for not having that courage. However, it's another to openly make sweeping changing to the ecosystem in an effort to make such things acceptable.
Have the courage to reject this type of thing for the sake of the overall project.