Return of the Block Size Wars on core

The debate concerning arbitrary limits on OP_RETURN outputs rages on core today. PR #32359 by Peter Todd has reignited the Bitcoin block size wars. He proposes to remove the long-standing restrictions on OP_RETURN data payloads in Bitcoin Core. Many opponents argue that this move could fundamentally erode the core ethos. Some cite susceptibility to abuse through meaningless inscriptions if the PR merges.

Todd’s position is that the current limits on data carrier outputs are ineffective and obsolete. He bases this position on the fact that miners can already bypass current set constraints through direct mempool submission, and projects like Libre Relay and MARA Slipstream make them trivial to circumvent. Again, he states that current restrictions incentivise harmful behaviour like stuffing nonstandard data into unspendable outputs, bloating the UTXO set permanently. From his perspective, the rational solution is to remove these legacy limits and stop pretending they’re serving any useful purpose.

The backlash has, however, been swift and substantial. A significant segment of the Bitcoin development community has issued firm concept NACKs to express deep concern over the broader implications of this move. Luke-jr, among others, argue that removing the datacarrier and datacarriersize config options strips node operators of a crucial policy tool. They see it as a form of central planning, eliminating local opt-outs in favour of a one size fits all policy that could expose the network to abuse.

Security implications are not just theoretical. Several critics, on all Bitcoin social layers, warn that unrestricted OP_RETURN payloads could be weaponised for mempool spam, flood and loot attacks, or fee market manipulation through RBF cycling. Even in a situation where the consensus rules remain intact, a larger OP_RETURNS could push more weight into blocks and memory, thus stressing node infrastructure, and this gets worse for users who run lightweight and resource constrained setups.

Like in the past ‘blob’ wars, a philosophical divide is immensely at play. Some acknowledge the inevitability of data anchoring use cases on Bitcoin. In their defence, they say standardising around OP_RETURN is a cleaner, more accountable method of data publication, compared to the alternatives already in use. Other engineers believe that this shift is being driven by corporate interests, with Citrea mentioned widely across social layers as a likely beneficiary.

I guess the heart of the matter is governance. Question is should Bitcoin Core maintain defensive barriers against non financial use cases, or adapt to reflect the reality that people are always going to embed data regardless? The other compelling question I ask is if it is the Core project’s job to enforce node-level choices? From my perspective, one thing is certain, the design choices on core should not be viewed as just technical, coz they are also very ideological. As seen in all these, the Bitcoin community is being forced to reexamine what kind of ecosystem Bitcoin should be.

How do you personally view Bitcoin’s role, pure money, a data layer, or something in between?