Last week, in a moment of uncharacteristically sneaky behavior, a small group of developers attempted to quietly change the default mempool policy of Bitcoin Core, the world’s dominant software for full nodes.
After re-introducing a failed 2023 proposal to raise the data storage capability of OP_RETURN outputs, critics flagged down the 2025 copycat before it merged into production. Colloquially, some are referring to the surprising incident as a sort of bitcoin OP_RETURN war.
Mononaut joked that it was akin to forking Bitcoin for quantum resistance, skipping the mailing list and BIP process, and jumping straight into merging code into production.
Critics called the Peter Todd-written pull request (PR) 32359 chaotic, insane, malicious, no consensus, shenanigans, and vandalizing. On the other hand, supporters said the PR would standardize mempool policy and modernize transactions that often catalogue arbitrary data elsewhere, even before this OP_RETURN proposal.
Ultimately, concerns about censorship of opposing viewpoints, deprioritizing bitcoin’s financial utility, and undisclosed corporate interests have halted PR 32359 from merging into mainnet.
OP_RETURN war for harm reduction
Backfooted, the camp in favor of lifting OP_RETURN’s datacarrier limit was quick to recast its actions as a valiant attempt at “harm reduction” for the long-term benefit of Bitcoin.
Devs from this camp explained their proposal with simple language. Allowing users to stuff large amounts of data into blocks via OP_RETURN was simply standardizing an already common practice of storing non-financial data into unconventional parts of bitcoin blocks like Taproot outputs.
From their perspective, users already store random text, images, computer code, and other non-financial data in bitcoin blocks anyway. Worse, many of them take advantage of the SegWit witness discount to pay significantly discounted storage rates.
Why insist on OP_RETURN’s 83 byte limitation when plentiful options exist elsewhere? Surely, it would reduce harm by normalizing OP_RETURN with other data storage options.
Read more: The corporate interests taking over Bitcoin development
Gallantly, some of them claimed that lifting OP_RETURN’s datacarrier limit was tantamount to “harm reduction.” It would, in their view, allow OP_RETURN payloads of 100 bytes or above “instead of Citrea forging ahead with writing permanently to the UTXO set.”
Citrea’s 100 byte payloads – 17 bytes larger than OP_RETURN’s limit
Venture capitalist-backed bitcoin project Citrea, according to senior bitcoin developer Peter Todd, needs to publish 100-byte data packets for certain operations. Unfortunately, it would publish unprunable outputs instead of the more desirable OP_RETURN, due to OP_RETURN’s 83-byte size limit.
Writing permanently to the set of unspent transaction outputs (UTXO), Citrea proliferated the number of UTXOs – requiring full nodes to download and use valuable computation to validate an ever-increasing quantity of Citrea-created UTXOs.
This was the “harm” that PR 32359 would have “reduced,” in the view of Mark “Murch” Erhardt on a detailed StackerNews thread.
Read more: Moderators censor Bitcoin devs as OP_RETURN war rages on
The Chaincode Labs bitcoin developer explained that lifting OP_RETURN’s datacarrier limit would allow corporate entities like Citrea to conduct its operations more efficiently – without requiring full node operators to download and validate excessive quantities of unprunable UTXOs.
Peter Todd, the creator of PR 32359 on the request of Chaincode Labs’ Antoine Poinsot, affirmed, “ I was asked to open [PR 32359] by an active Core dev because entities like Citrea are using unprunable outputs instead of OP_Return, due to the size limits.”
Jameson Lopp says there is no conflict of interest
Jameson Lopp, a Citrea investor and advocate for PR 32359, denies that his investment in Citrea created a conflict of interest regarding OP_RETURN’s datacarrier limit.
According to his cited explanation, “The Citrea protocol does not benefit from this change at all! We’re just asking them nicely to please use OP_RETURN and not bloat the UTXO set.”
In any case, the request to change this important default value of Bitcoin Core software – not to mention restricting the ability of users to self-configure that value as self-sovereign Bitcoin Core node operators – has resulted in a brief sort of OP_RETURN war among bitcoin maintainers this month.
Arguments continued over the weekend and will likely continue this week as a frenzy of social media across GitHub, the Bitcoin-Dev Google Group, StackerNews, Reddit, BitcoinTalk, X, and elsewhere.
