Last week, alarm bells rang over a proposal to relax data storage limitations via an operation code of Bitcoin script.

It was a deceptively minor change to the policy of full node software that shed light on the corporate interests encroaching on Bitcoin’s technical development.

Last week, alarm bells rang over a proposal to relax data storage limitations via an operation code of Bitcoin script.

It was a deceptively minor change to the policy of full node software that shed light on the corporate interests encroaching on Bitcoin’s technical development.

Instead of rubber-stamping the idea, technical Bitcoiners sprang into action, whipping up support for their side of the debate. Critics revealed the commercial interests of companies like Citrea and an assortment of zero-knowledge (ZK) and Bitcoin virtual machine (BitVM) companies that are pushing developers to raise data storage abilities.

In a sly request to tweak the world’s most popular full node software, Bitcoin Core, a few developers seemed to believe that lifting OP_RETURN’s datacarrier output limit from 83 to hundreds of thousands of bytes would achieve quick consensus and earn nearly immediate approval from Bitcoin Core maintainers.

Although sophisticated users have always been able to privately broadcast large OP_RETURN transactions to miners via Libre Relay or MARA Slipstream, Bitcoin Core’s standardness rules for queueing transactions across its default mempool denied OP_RETURN outputs exceeding 83 bytes.

Lifting its datacarrier cap would have changed an important standardness rule for transactions and allowed large quantities of non-financial data to propagate across the mempools of tens of thousands of Bitcoin Core nodes as operators progressively updated their software.

Usually a conservative developer, a self-empowered Peter Todd opened pull request (PR) 32359 at the request of Chaincode Labs’ Antoine Poinsot.

The GitHub comment section went viral, and within hours, moderators started muting and censoring participation as fiery posts blamed developers and their corporate backers.

One critic chimed in, “The PR seems to anticipate some company’s mere intent. Are we now shapeshifting Bitcoin to whatever people publish they might be doing? Bitcoin has a purpose and it’s not appeasement.”

Moderators’ rarely-exercised power of censorship on GitHub only attracted more attention to the debate. Observers even blamed Todd for using PR 32359 to quietly re-introduce his PR 28130 that failed to achieve consensus in 2023.

He used generous language for his request, including “uncap datacarrier by default” or “remove arbitrary restrictions on OP_RETURN by default.” In reality, the proposal’s real intent was to stop filtering large quantities of non-financial data — important context that seemed obscured by the technical description.

Many Bitcoin developers are opposed to policies that encourage the use of its limited storage capabilities for non-financial information like pictures, games, business data, or other forms of media unrelated to BTC transactions.

if you're interested in the conversation from 2 years agoThis is NOT* the one from this year.A failed proposal, again, with even less configurability

Specifically, critics blamed Todd for re-introducing an even more generous version of his 2023 code by withholding a config option.

Rather than leaving the OP_RETURN datacarrier limit as a configurable piece of code — such as raising the number from 83 to several hundreds of thousands of bytes, and leaving the digits available for self-configuration — Todd simply removed the config code entirely in order to prevent users from setting any custom number.

In other words, critics blamed Todd for attempting to slide a change through with a bit of wet glue that would cement its dominance once implemented — preventing users from modifying the number themselves on their own node.

In short, it was disrespectful to Bitcoin Core’s ethos of consensus-based software development.

According to Todd’s code, the change would be drastic: lifting the OP_RETURN datacarrier limit from 83 bytes up to just under the full, 1MB limit of a single block, less other data — and disallowing Bitcoin Code node operators from having the option to adjust that limit manually.

This was particularly offensive to the self-sovereign ethos of Bitcoin, which values the ability of node operators to choose their own mempool and transaction relay policies.

The more I look into it the worse if gets.Again this isn't a technical debate. It's just bad actors pushing malicious changes into Bitcoin lying about the effects it will have.Citrea *need* your mempool to tolerate their junk, and Core are determined to help them with that by…

As tensions swirled, many people also blamed the corporate interests of the leading spokesman for PR 32359, Jameson Lopp. One of his companies, Citrea, has raised millions of dollars from venture capitalists and could benefit from publishing larger-than-83 byte quantities of data via Bitcoin’s OP_RETURN datacarrier.

Citrea supports a suite of third-party applications and businesses, including altcoin token exchanges, DAOs, oracles, and yield-bearing stablecoins.

There