Interpret the real reason why Bitcoin Core v30 relaxed the OP

Author: Aaron Zhang; Source: X, @zzmjxy

Bitcoin Core v30 relaxes the OP_RETURN restriction. Everyone is saying that it is because “Ordinals inscription restriction is invalid”.

Over the past three months, I’ve delved into the Bitcoin Core v30 mailing list, Citrea white paper, and related technical documentation.Discover a truth that everyone ignored: The real reason for the OP_RETURN policy change was not Ordinals at all.It’s BitVM.

This story is more important than the Ordinals narrative.From this perspective, no one in the Chinese and English communities has ever talked about it.

Case background

In April 2024, Citrea released the first complete BitVM bridge-Clementine.

It is the first zkRollup on Bitcoin, using BitVM for L1 verification.

Then they ran into a technical problem: 144 bytes of anchor data needed to be published on-chain.

Technical requirements

These 144 bytes include:

128 bytes: Groth16 zero-knowledge proof
16 bytes: total accumulated work (total proof of work)

This data was used by Watchtower to prove they had the correct Bitcoin chain when questioning the Operator.Here’s the problem: OP_RETURN only allows 83 bytes.not enough.

Core technical constraints

Some people may ask: Why not put it in witness?Like Ordinals?Key difference: Citrea’s subsequent validation transactions require reading this data.

Bitcoin Script cannot reference the witness data of the previous transaction.So the data **must** be at the scriptPubKey location, this is not optional.

Technical principles

Simply put it is:

Witness data:

It can only prove that “the current transaction is valid”✓
Cannot be read by subsequent transactions ✗

scriptPubKey data:

Can be referenced by scripts in subsequent transactions ✓

BitVM’s verification logic requires chained references, so scriptPubKey must be used.

forced plan

83 bytes wasn’t enough, so Citrea was forced to use a terrible approach: creating “unspendable” Taproot outputs that disguised the data as public keys.

Specific methods:

Output 0: OP_1 <The first 32 bytes are disguised as public key>
Output 1: OP_1 <32 bytes disguised as public key>
Output 2: OP_RETURN <80 bytes remaining>

These “public keys” have no corresponding private keys at all.It will never be spent.

hazard analysis

The problem with this solution: permanently inflating the UTXO set.

Each WatchtowerChallenge transaction creates two UTXOs that can never be cleaned up.All full nodes must store these “fake public keys” permanently.This is exactly the worst-case scenario that Core developers have been trying to avoid.

Mailing list original text

Antoine Poinsot clearly wrote in the proposal:

“Clementine uses unspendable Taproot outputs to store data… due to size limitations of OP_RETURN”

This case **directly triggers** the OP_RETURN policy change proposal.Original email.

Developer’s logic

Core developers’ thinking chain:

Current situation: Citrea uses fake UTXO (bad)
Future: More BitVM projects will follow suit
Or: they use naked multisig (like the Stamp protocol)
Conclusion: It is better to let go of OP_RETURN and provide a “less harmful” path

This is a harm reduction strategy.

BitVM’s strategic position

Why is Core willing to “open the way” for BitVM?Because BitVM is an important direction of Bitcoin L1 innovation.

Blockstream CEO Adam Back said: “BitVM’s anchor mechanism is an important direction of L1”

If the BitVM ecosystem develops:

Various zkRollups
Cross-chain bridges
Complex on-chain verification

There will be similar anchoring needs.

The essential difference from Ordinals

Ordinals vs BitVM anchor data:

Ordinals:

Location: Witness (can be pruned)
Motive: Speculation/Art
Characteristics: May fade

BitVM anchor:

Location: scriptPubKey (must be permanent)
Motivation: Infrastructure security needs
Characteristics: Long-term growth demand

Completely different technical scenario.

Conclusion

Therefore, the OP_RETURN policy change of Bitcoin Core v30 is not a surrender to Ordinals, but an active guide for the BitVM ecosystem; it is not a passive response to speculation, but a way to pave the way for technological innovation in advance.This is forward thinking from Core developers.

Therefore, the focus of Core has never been JPEG, but:

Paving the way for future VMs (BitVM/Simplicity/Covenants)
Clean up the special rules left over ten years ago so that the system can continue to evolve
Avoid the policy layer becoming an “invisible consensus” that limits innovation

Master these, and you will grasp the technical direction of Bitcoin in the next ten years.It’s not just a war of words between vs. Ordinals and vs. Knots, but a true understanding of the logic of technological evolution.