Bitcoin Core v30 introduces controversial OP_RETURN changes

Bitcoin Core, the dominant software powering roughly 80% of all BTC nodes, has rolled out its long-awaited v30.0 update.

The update, published on Oct. 11, brings optional encrypted node connections, performance and fee optimizations, and several bug fixes.

Yet the change to OP_RETURN, Bitcoin’s built-in “data graffiti wall,” has triggered the loudest response.

What Changed in OP_RETURN?

OP_RETURN allows users to attach metadata such as text, images, or digital signatures to Bitcoin transactions without affecting their monetary function. Until now, each OP_RETURN output could carry up to 80 bytes of data, keeping non-financial use cases constrained.

The new release expands that limit to 100,000 bytes and allows multiple OP_RETURN outputs per transaction to be relayed and mined by default.

In practice, that means node operators running v30 can now process transactions embedding larger or more complex data structures from NFT-style inscriptions to application metadata without manual configuration.

Developers describe the change as enabling richer on-chain experimentation. One market analyst claimed:

“OP_RETURN is made to be used. Imagine the power of an uncensorable, unmodifiable registry. Victors can’t rewrite history. Humanity can inscribe facts from their own point of view, at that precise moment. [This is] a gold mine for future historians and an incredible leap for humanity.”

However, others warn it could accelerate blockchain bloat and fee pressure if users flood the mempool with oversized data files.

According to Mempool Research data, inscriptions and OP_RETURN transactions already account for 40% of all Bitcoin transactions by count, 10% by fees, and 28% by weight.

Considering this, a wider adoption of these data-heavy transactions could push Bitcoin’s average block size beyond its current 1.5 MB to as high as 4 MB per block – a jump that could reshape network economics.

Community split: utility or spam?

The change has sparked heated debate among Bitcoin developers and node operators.

Some see it as a natural evolution that gives Bitcoin parity with smart-contract-capable chains like Ethereum. Others argue it risks diluting Bitcoin’s core role as a peer-to-peer financial network.

Prominent developer Luke Dashjr criticized the change, saying Core 30 “broke” the datacarrier size control and deprecated it entirely, allowing more “spam outputs” per transaction.

According to him:

“Bitcoin does not support data storage beyond (at most*) 80 bytes (in OP_RETURN, but that’s not material) attached to a financial transaction; or 95 bytes per block in the coinbase. That is not large enough for CSAM. Exploiting vulnerabilities, as with Inscriptions, is not a supported behaviour/use case, just an abuse of script opcodes. It is not storing data per se, just harming Bitcoin with bogus garbage scripts. Expanding OP_RETURN increases the size of _supported_ data storage, large enough to include CSAM.”

Considering this, he described v30 as “malware ” and urged a “mass migration to Knots,” an alternative client that enforces stricter policies.

Yet, Blockstream CEO Adam Back countered that vilifying OP_RETURN changes amounts to “attacking Bitcoin.”

According to Back, the update includes legitimate security and robustness fixes from “some of the most skilled developers on the planet.”

What next?

Amid the rift, some community members have proposed policy-level compromises for the update.

Nick Szabo, a renowned cryptographer, suggested:

“Deprecate use of OP_RETURN for financial transaction functionality going forward; add ability to prune the newer while keeping the older OP_RETURNs.”

Meanwhile, BitMEX Research highlighted the concept of OP_Return2, a soft-fork mechanism allowing transactions to commit to hashes of up to 8 MB of external data, without forcing full nodes to validate or store it.

According to the firm, the proposal could preserve data integrity while reducing on-chain bloat.

However, researchers caution that miners might have little incentive to include such transactions if fees do not offset the extra complexity. They also note that similar timestamping functions already exist at a lower cost.

Mentioned in this article