The corporate interests taking over Bitcoin 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.
Read more: FixTheFilters: Bitcoin arguments go viral over relaxing Core data storage
Pull request 32359: Re-introducing a failed 28130
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.
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.
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.
More corporate interests in bitcoin development
There are, of course, other corporations interested in tweaking Bitcoin Core to better suit their interests.
For example, Stacks Foundation announced a $500,000 Stacks Working Group meant to improve BitVM’s security. If the initiative worked, BitVM would provide computing support for Bitcoin Layer 2 apps like Stacks (STX) itself, data roll-ups, trust-minimized bridges, and other projects.
One critic summarized the unspoken motivation for PR 32359: “On the OP_RETURN drama, what actually triggered this is the BitVM folks about to launch a protocol that needs to commit ~100 bytes of data and the current OP_RETURN limit being too restricted for that. So they ‘fixed’ that.”
A few critics even blamed Taproot Wizards for the incident, which raised $30 million to re-enable an operation code, OP_CAT, and publish various types of non-financial data into Bitcoin blocks.
OP_CAT is an original operation code developed by Satoshi Nakamoto, who later turned it off due to concerns about errors. Efforts to bring it back include BIP 347, which introduces OP_CAT alongside Tapscript.
In general, Taproot Wizards have been a well-funded group arguing for quicker, experimental changes to Bitcoin Core. However, executives at Taproot Wizards clarified that neither of their NFT-like inscription collections, Taproot Wizards and Quantum Cats, used OP_RETURN to store picture data.
Instead, those collections inscribed data using separate, witness data.
In the end, it is likely that PR 32359 will not gain consensus and will expire in contention. Nevertheless, its surprise introduction with secret motivations has raised awareness about the corporate interest seeking to influence Bitcoin Core developers.
Going forward, the community might ask deeper questions about who stands to benefit the most from an otherwise technical PR. One way to discover those motivations is to follow the money.
Got a tip? Send us an email securely via Protos Leaks. For more informed news, follow us on X, Bluesky, and Google News, or subscribe to our YouTube channel.