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