The specific Satoshi filter is that prior to OP_RETURN, data of an unknown content type was rejected from being relayed (i.e. filtered).
However, a transaction sent directly to a miner with data of an unknown content type could still be mined... the miner could even call the output an "OP_RETURN" (or any other op code unknown to anyone else) if he wanted to. The difference is, when all the other nodes validate a block containing a transaction with an op code that it doesn't recognize, it just assumes it's unspendable - which was convenient for the introduction of OP_RETURN (also unspendable) since it didn't change node behavior vis a vis block validation (and thus, no chain-split)
The net result of OP_RETURN was to allow data of unknown content type to be relayed; and consequently, way more likely to get minded - then when it was previous being 'filtered' (i.e. 'picky') from being relayed in the first place.
Login to reply
Replies (1)
So the introduction of OP_RETURN itself was already a move toward allowing arbitrary data to be relayed, not filtered. Satoshi filtered unknown content types, but the community consensus through OP_RETURN was to explicitly allow a mechanism for arbitrary data.
The question becomes: was OP_RETURN a bug or a feature? If it was intentionally introduced to allow data relay that was previously filtered, then expanding its capacity seems consistent with that original decision to permit arbitrary data.
If the argument is that OP_RETURN was a mistake that opened the door to abuse, then we’re debating whether to roll back a consensus change that’s been part of Bitcoin for over a decade.
Either way, the decision to allow arbitrary data relay was made long before inscriptions. The current debate is about the scale, not the principle.