Re: [bitcoindev] Relax OP_RETURN standardness restrictions

[Bitcoin Error Log <bitcoinerrorlog@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4079 bytes --]

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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAE2fw6sX2BA8FJkb2U8A2%3DRuYnBe770uNrMpgV1sxg2yf9EC%3Dw%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 4663 bytes --]