[Long Thread] The Overlooked Truth: The Real Motivation Behind Bitcoin Core v30 Lifting the OP_RETURN Restriction

Chainfeeds Guide:

The OP_RETURN policy change in Bitcoin Core v30: this is not a surrender to Ordinals, but a proactive channeling for the BitVM ecosystem. It is not a passive response to speculation, but a move to pave the way for technological innovation in advance. This reflects the forward-thinking mindset of Core developers.

Source:

Author:

Aaron Zhang

Opinion:

Aaron Zhang: 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 encountered a technical challenge: they needed to publish 144 bytes of anchor data on-chain. These 144 bytes include 128 bytes for the Groth16 zero-knowledge proof and 16 bytes for total accumulated work (proof of total work). This data is used when the Watchtower challenges the Operator, to prove they possess the correct Bitcoin chain. Here’s the problem: OP_RETURN only allows 83 bytes. That’s not enough. Some might ask why not put it in the witness, like Ordinals? The key difference is that Citrea’s subsequent verification transactions need to read this data. But Bitcoin Script cannot reference the witness data of a previous transaction. Therefore, the data must be in the scriptPubKey position—this is not optional. Simply put: witness data can only prove the validity of the current transaction, but cannot be read by subsequent transactions. scriptPubKey data can be referenced by the Script of subsequent transactions. BitVM’s verification logic requires chained referencing, so scriptPubKey must be used. With 83 bytes not being enough, Citrea was forced to use a very poor method: creating "unspendable" Taproot outputs, disguising the data as public keys. The problem with this solution is that it permanently inflates the UTXO set. Each WatchtowerChallenge transaction creates two UTXOs that can never be cleaned up. All full nodes must permanently store these fake public keys. This is exactly the worst-case scenario that Core developers have always wanted to avoid. The Core developers’ chain of thought: the current situation is that Citrea uses fake UTXOs (bad), and in the future, more BitVM projects may follow suit or use bare multisig (like the Stamp protocol). The conclusion is that it’s better to relax OP_RETURN and provide a "less harmful" path. This is a harm reduction strategy. Why is Core willing to pave the way for BitVM? Because BitVM is an important direction for innovation on Bitcoin L1. Blockstream CEO Adam Back once said: "BitVM’s anchor mechanism is an important direction for L1." If the BitVM ecosystem develops: various zkRollups, cross-chain bridges, and complex on-chain verifications will all have similar anchoring needs.