Nostr Web Client

If Core neglected to update spam filters and refuses to fix the vulnerability, that sounds like the Core development consensus chose not to restrict it. Whether through action or inaction, that became Bitcoin’s reality post Taproot.

On Satoshi’s filters: can you point to specific examples where Satoshi rejected transactions based on content type rather than structural validity? I want to understand the historical precedent you’re citing.

On Core 30 and Taproot: if they’re unrelated, what specifically is Core 30 changing that enables the threat you’re warning about?

On “each user decides” agreed. But there’s a difference between individual nodes filtering their own mempools versus advocating that filtering should be the standard. Your post isn’t just “here’s what I’m doing”, it’s “everyone should do this NOW.” That’s attempting to establish collective filtering as the norm, not individual choice.

Judge Hardcase 2mo ago 💬 1

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.

Reply to this note

Please Login to reply.

Discussion

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.

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.