Nostr Web Client

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.

Contra 2mo ago 💬 2

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.

Reply to this note

Please Login to reply.

Discussion

Judge Hardcase 2mo ago 💬 1

'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.

Contra 2mo ago

Fair correction on OP_RETURN not being a consensus change since it didn’t require nodes to align. I appreciate the clarification.

On the scale question: if the original introduction of OP_RETURN was itself a compromise on principles, then the current debate about expanding it is really about whether that compromise should hold or shift further.

My concern is that scale debates become legitimacy debates. Once we accept that limiting arbitrary data is about protecting Bitcoin’s purpose rather than just technical constraints, we’re making ongoing judgments about what belongs. That feels like a different kind of governance than protocol rules.

But I take your point that witness data stuffing is a separate mechanism from OP_RETURN expansion, even if they’re related in practice.

7fc62867... 2mo ago

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.