From what I understand, things like inscriptions can only be inserted between two specific flags - OP_FALSE and OP_IF. Having a validation check to reject witness scripts that have arbitrary data between these two flags could be used to reject inscriptions while still allowing all the benefits of taproot. This will prevent people from overloading the network with txns geared solely for ordinals and brc-20 tokens.

Unfortunately, there are many other ways to “inscribe” other than that particular trick.

Is there a reason such a validation check is a bad idea? We already have OP_RETURN to store arbitrary data that is limited to 80kb. Was it an oversight that arbitrary data can be inserted between OP_FALSE and OP_IF when the size limit for witness scripts was lifted as part of taproot?

There have been some of us that had hoped for a slightly larger OP_RETURN such that we can store a tagged root of a hash-tree (~128-512 bytes). For instance, open time-stamps, ION, and my own privacy-focused Gordian Envelope (https://www.blockchaincommons.com/introduction/Envelope-Intro/), all consolidate large sets of proofs into a hash, which we use for L2 proofs-of-inclusion. My own preference is that the size can be large enough so you can store the hash, optionally have a signature on it, and have a few bytes for self-describing data (we like CBOR as it is quite small).

All of us held off for years asking for larger OP_RETURN or standardizing on a pay-to-contract BIP for the techniques we do use because of objections to putting anything on-chain. But now we are dismayed by the inscription technique that freeloads on the network mempool, the validation network, and volunteer unpruned full nodes.

For instance, I host an alternative explora instance (the source code base used by blockstream.info), offering it publicly via Tor so that there is more than a single server offering its details. Inscriptions combined with DOS attacks on Tor is making it more expensive for me to host and maintain this free privacy service.

There was a recent thread discussing raising the limit on OP_RETURN https://github.com/bitcoin/bitcoin/issues/27043

Here is an old relevant thread from open time-stamps: https://github.com/opentimestamps/python-opentimestamps/pull/14

I’m not sure what the solution is. I feel like I’ve been a good neighbor for some time on this topic, always recommending minimal on-chain data, and now I feel frustrated with this free-rider problem.