Bitcoin Core, which powers approximately 80% of all BTC nodes, has launched its much-anticipated v30.0 update.
Released on Oct. 11, the update introduces optional encrypted node connections, optimizations for performance and fees, as well as various bug fixes.
However, the modification to OP_RETURN, Bitcoin’s native method for attaching data, has sparked the most discussion.
What Changed in OP_RETURN?
OP_RETURN enables users to add metadata like text, images, or digital signatures to Bitcoin transactions without interfering with their monetary function. Previously, each OP_RETURN output was limited to 80 bytes of data, which restricted non-financial applications.
The latest version increases this limit to 100,000 bytes and allows multiple OP_RETURN outputs per transaction to be processed and mined by default.
This means that node operators running v30 can now handle transactions containing larger or more intricate data formats, ranging from NFT inscriptions to application metadata without the need for manual setup.
Developers see this adjustment as a means to facilitate richer on-chain experimentation. A market analyst stated:
“OP_RETURN is designed for use. Picture the potential of an unalterable, uncensorable registry. The victors can’t rewrite history. Humanity can etch facts from their perspective at that moment. This is a treasure trove for future historians and a giant leap for mankind.”
On the flip side, some critics argue that this could lead to blockchain congestion and increased fee pressures if users inundate the mempool with large data files.
According to Mempool Research, inscriptions and OP_RETURN transactions account for 40% of all Bitcoin transactions by count, 10% by fees, and 28% by size.
This trend could lead to an increase in Bitcoin’s average block size from the current 1.5 MB to as much as 4 MB per block, significantly altering network dynamics.
Community Split: Utility or Spam?
This change has stirred intense discussions among Bitcoin developers and node operators.
Some view it as a necessary progression that aligns Bitcoin with smart-contract-enabled platforms like Ethereum. Others believe it risks undermining Bitcoin’s fundamental purpose as a peer-to-peer financial network.
Developer Luke Dashjr has condemned the modification, claiming that Core 30 “disrupted” the data carrier size control and rendered it obsolete, leading to more “spam outputs” in transactions.
He expressed:
“Bitcoin does not support data storage beyond (at most*) 80 bytes (in OP_RETURN, which isn’t substantial) attached to a financial transaction; or 95 bytes per block in the coinbase. That is not sufficient for CSAM. Taking advantage of vulnerabilities, as seen with Inscriptions, is not an acceptable behavior/use case, but rather an abuse of script opcodes. It is not storing data per se, just damaging Bitcoin with meaningless garbage scripts. Expanding OP_RETURN increases the size of _supported_ data storage, sufficient to include CSAM.”
In light of this, he described v30 as “malware” and called for a “mass migration to Knots,” an alternative client enforcing stricter standards.
Meanwhile, Blockstream CEO Adam Back countered that criticizing OP_RETURN modifications constitutes “attacking Bitcoin.”
Back argues that the update contains genuine security and robustness improvements from “some of the most skilled developers in the industry.”
What Next?
In the midst of the divide, some community members have suggested policy-level compromises related to the update.
Nick Szabo, a respected cryptographer, proposed:
“Deprecate the use of OP_RETURN for financial transactions moving forward; introduce a mechanism to prune newer OP_RETURNs while retaining older ones.”
In addition, BitMEX Research highlighted the notion of OP_Return2, a soft-fork strategy that permits transactions to reference hashes of up to 8 MB of external data, without necessitating full nodes to validate or store it.
They assert that this proposal could maintain data integrity while minimizing on-chain bloating.
However, researchers caution that miners may have little motivation to include such transactions if the fees do not justify the added complexity. They also mention that similar timestamping functionalities already exist at a lower expense.
