Bitcoin Core’s Removal of the OP_RETURN Limit Sparks Sharp Division

The upcoming release will, by default, lift the 80-byte ceiling that previously restricted transaction-embedded data

Plans by Bitcoin Core to remove the long-standing OP_RETURN limit have sparked sharp division across the ecosystem.

The upcoming release will, by default, lift the 80-byte ceiling that previously restricted transaction-embedded data, presenting the change as a modernization of policy in response to shifting network practices.

Originally introduced as a soft deterrent, OP_RETURN allowed users to embed small, provably unspendable data without bloating the unspent transaction output (UTXO) set. The limit aimed to prevent abuse while enabling legitimate use cases such as timestamping or cryptographic commitments.

However, the cap has increasingly proved ineffective. Developers, including Greg “instagibbs” Sanders, argued that the existing ceiling merely shifted these activities into more opaque alternatives that undermined network health.

In a public statement, Sanders noted that “large-data inscriptions are happening regardless.”

"We're rendering these inscriptions unreadable by refusing to process transactions with unsupportable script types or cooperating with attempts to disable dust limits. We're also making it harder for miners to accept unserializable transactions or transactions that violate node policy in other ways."

Pointing out that "persistent actors will continue to attempt to circumvent these measures," rendering the inscriptions readable seems like a natural progression.

"Inscriptions are a fact of life. Let's move them out of script and into the open, simplify relay and fee estimation, and collect these outputs into a single, provably unspendable structure."

Aligning behavior with miners

The move also saw the deprecation of the “-datacarriersize” parameter in pull request #32406.

These changes align Core's behavior more closely with how miners and other node implementations already operate. Unlike consensus rules, which govern what can be included in blocks, standardness rules such as the OP_RETURN cap primarily dictate how transactions are relayed across the peer-to-peer network.

As such, removing the ceiling does not force a change in what miners can include in blocks but recalibrates policy to match the real-world conditions that miners and other nodes already factor into their behavior.

However, criticism of the move has been voiced by prominent figures who view the decision as deviating from Bitcoin's minimalist ethos.

Luke Dashjr, maintainer of Bitcoin Knots—an increasingly popular alternative client with almost 5% of nodes—described the removal as "utter insanity."

Samson Mow, CEO of Jan3 and an outspoken Bitcoin advocate, suggested that operators who wish to reject the change can do so by running Knots or staying on older versions of Bitcoin Core.

According to Mow, maintaining stricter relay policies is crucial to preserve Bitcoin's role as a global, censorship-resistant monetary network.

Nevertheless, Mow pragmatically recognized that the removal of the limit has its advantages.

"Delete the cap. Aligns default policy with actual network practice, minimises incentives for harmful workarounds, and simplifies the relay path.

Option 3 earned broad, though not perhaps unanimous, support. Dissenting parties remain free to modify software, run stricter policy, or propose new resource limits if empirical harm emerges."

Those in favor of removing the limit highlight the fact that with blocks still subject to four million weight units, dust limits, and other constraints, fears of unchecked data spam are overstated.

They argue that removing arbitrary barriers makes relay and fee estimation more predictable and encourages cleaner data use by consolidating inscriptions into provably unspendable OP_RETURN outputs rather than misusing spendable script paths.

A broader shift in programmability

The timing of the OP_RETURN policy shift coincides with growing momentum for more ambitious protocol upgrades.

Once a memetically disabled opcode assigned to OP_SUCCESS126 in BIP-347, OP_CAT has advanced to become a subject of serious discussion and proposal among developers and industry researchers.

Galaxy Digital's research team positioned both OP_CAT and OP_CTV as straightforward enhancements that could be coded in a few days and boasted major implications for DeFi applications.

"Unassigned opcodes and opcode variants can be used to introduce new capabilities to the VM. This is done by modifying the node software to recognise and process transactions that use these codes in a defined way. Once an opcode is assigned, it can be used in transactions to perform a specific operation or function.

For example, a new opcode could be used to enable support for a new type of cryptographic signature scheme, or to introduce a new class of script operations that could be used to build more complex contracts."

With discussions on activation paths now ongoing, and proposals such as A Complete Union: Merging Bitcoin Improvement Proposals (March 2024) detailing integration of OP_CAT and PayToMany into a single upgrade package, the trajectory of this initiative suggests that Bitcoin's programmability may soon expand further.

Together, these developments present a deeper tension around Bitcoin's identity.

Those in favor of more permissive data policies view this evolution as pragmatic,