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.
Replies (2)
'bug' or 'feature' is ultimately a matter of perspective... and the community - through the collective decisions of its independent actors - will eventually settle on a resolution (or it won't and fork).
I'm not sure what you mean by rolling back a 'consensus change'; but, as I indicated, nodes don't have to be in alignment on recognizing "OP_RETURN" or not in order to avoid a chain-split. As such, introducing OP_RETURN wasn't a change to the consensus rules in the first place.
The debate was always about scale - which resulted in a compromise from each side on their principles... but yeah, witness-data stuffing (e.g. inscriptions) are a separate issue.
There’s a big difference between “expanding its capacity” to say 160 bytes and removing the limit entirely as Core v30 does. I think there would be much less concern if this was an increase to 160 bytes to support some vaguely plausible use-case.
