I think it’s worth raising a meta-topic in light of the OP_RETURN debate: namely, the importance of respecting the status quo as consensus, and the need for Bitcoin Core to distance itself from acting as a governance body.
Most of you appreciate the idea of respecting user space, and the principle that consensus is most easily expressed by the software already being run. That’s the essence of Bitcoin’s credibility. In this specific case, I don’t even care about the outcome. The utility and consequence of policies and data use cases are already fundamentally accounted for in Bitcoin’s design. It just isn’t a big deal. But here are some things I think we should consider: 1. Even if we tweak OP_RETURN, Bitcoin Core will still enforce policies that reject certain valid transactions, even when they are harmless (non-flagged RBF, for example). The only way to eliminate this form of protocol-level censorship is to remove the policy engine’s influence from consensus-critical infrastructure altogether. As long as Core shapes what is considered standard, it acts as a gatekeeper. True neutrality requires removing these centralized filters, not tweaking them. We should not be arguing over user-configurable settings in something called "Core." 2. Mempool fragmentation isn't caused by inscriptions alone. Fragmentation of the mempool arises from disharmony, complexity, and policy change, not from any specific class of transactions. Bitcoin Core is not the only implementation and the default config is not the only config. Adding a small set of explicit data use cases to OP_RETURN would not prevent users from continuing to encode data in Taproot outputs or other mechanisms for other reasons. 3. If Core plans to make Taproot witness data pruneable (they do, right?), then the very premise of this conflict becomes largely irrelevant. Is the UTXO “pollution” argument moot? 4. Even if you give data users a clean OP_RETURN path, the original reasons for encoding data elsewhere haven’t gone away: • They may want resistance to censorship, since OP_RETURN data is potentially filterable. • They may want to emulate “first-seen” behavior for zero-conf coordination, especially in merchant or custodial systems. • They may simply not trust Core’s intentions, fearing future reversals or targeted policy changes. Fragmentation doesn’t go away by offering alternatives, it follows incentives and distrust. Additional encoding options will coexist with existing ones, not replace them. 5. Bitcoin Core should avoid being a governance body. Core’s behavior has shown a pattern of shaping Bitcoin policy outside of consensus, through policy enforcement and behavioral changes that affect what nodes and miners relay and accept. This is de facto governance. Therefore, every Core policy change, especially those affecting transaction relay or validation, should be rejected by default (unless, MAYBE, they emerge organically, from actual consensus in the wild or from config-based downstream distros). The most dangerous centralizing force in Bitcoin today is not Ordinals or data use, it’s Core acting as a de facto standards body, redefining behavior outside the consensus process. If we are serious about decentralization, we must decouple policy from protocol, and resist all attempts by any one group to dictate Bitcoin’s rules unilaterally. Also consider that, compared to the drama and disruption, the utility/scaling/impact of Bitcoin rule changes overall, aside from the blockspace increase, has been a disappointment anyway. ~John Carvalho -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAE2fw6sX2BA8FJkb2U8A2%3DRuYnBe770uNrMpgV1sxg2yf9EC%3Dw%40mail.gmail.com.
