OP_RETURN WARS: The Complete Chronicle

Welcome to BitcoinFi Weekly. We cover where people use their BTC and what is changing in the Bitcoin world.

This week, I’m covering the decade-long saga of OP_RETURN, the  Bitcoin opcode that sparked one of the protocol’s most significant fights. Added in 2010 to let users store small bits of data onchain, it stayed quiet until projects began using it for tokens, metadata, and non-financial applications. That triggered limits, pushback, and years of debate. Fast forward to 2025, a proposed change to restrict OP_RETURN reignited the fire, leading to weeks of infighting, reversions, and broader questions about what Bitcoin should allow. The dust has seemingly settled, but the debate over Bitcoin’s purpose is far from over.

OP_RETURN never really was about a few bytes of arbitrary data. Instead, it catalyzed discussions about changes, who makes them, and what kind of system Bitcoin can become.

Table of Contents

1. Quick Glance Timeline
2. How Bitcoin Learnt to Hate Junk (2010-2013)
3. The 80-Byte Gentleman’s Agreement (2014-2020)
4. Pandora’s Witness: SegWit Discount + Taproot (2021)
5. The Non-Standard Underground Grows (2022-2024)
6. Roll-ups Knock: The Citrea Catalyst (Early 2025)
7. Tribal Pull Requests Warfare (May 2025)
8. The War Winds Down: Knobs, Knots & the Poinsot Doctrine
9. Technical Reality Check: Fact vs Fiction
10. Final Take: The Case for a Bigger OP_RETURN

Quick Glance Timeline

2.How Bitcoin Learnt to Hate Junk (2010-2013)

Bitcoin’s origin story is usually told as a tidy march of breakthroughs: the white paper, the first block, pizza day, hyper-bull markets. Yet from the very start—and right up through today’s OP_RETURN brawl—another, less tidy struggle has pulsed beneath the surface: what, besides money, gets to live forever onchain?

To understand the OP_RETURN wars today, we need to go back to 2010. Barely a year into its existence, Bitcoin was already facing theoretical challenges to its purpose. In a forum thread titled Transactions and Scripts, a cypherpunk named Gavin Andresen raised a prescient concern. "I could encode all sorts of interesting information in the TxOut script," he wrote, "and... it would be a useful covert broadcast channel. That's a cool feature until somebody decides to flood the network with millions of transactions to transfer the latest Lady Gaga video to all their friends."Satoshi answered the next afternoon with the shrug that would echo for years: “That’s what fees are for. There are other things we can do if necessary.” It was classic Nakamoto—half laissez-faire, half cryptic threat. Fees, he implied, would price out vandals; and if that failed, unnamed “other things” sat in reserve.

Those lines hardened into a constitutional preamble: the chain was open, but not free. Yet openness is an invitation, and by 2011, developers discovered Bitcoin scripts could hide data. They began embedding data (hex strings and messages) into scriptSigs and P2SH redeem scripts. These "data UTXOs" weren't temporary visitors; disguised as spendable outputs, they permanently occupied the UTXO set that every full node must maintain to prevent double-spending. This so-called “junk accumulation” became the Original Sin of Bitcoin hygiene.

Then, in 2013, “Colored Coins” emerged. Colored coins allowed tagging of individual satoshis to represent other assets like shares, tickets, or deeds. While innovative, implementations often created numerous tiny 1-satoshi outputs across the ledger. The UTXO set expanded rapidly. Core developers recognized a threat to Bitcoin's fundamental design: if every node had to permanently store an ever-growing collection of digital artifacts, running a node would require increasingly powerful hardware, endangering decentralization. They needed a solution allowing data to exist onchain without forcing nodes to store it permanently.

3. The 80-Byte Gentleman’s Agreement (2014-2020)

In March 2014, Bitcoin Core 0.9.0 introduced OP_RETURN as the official solution, with the release notes explicitly stating this was "not an endorsement of storing data in the blockchain" but rather a way to "avoid data storage schemes" that were "bloating bitcoin's UTXO database."Fundamentally, OP_RETURN allowed for the inclusion of a small amount of arbitrary data in a transaction. OP_RETURN immediately marks the transaction output as unspendable, ensuring that the output can't be used as an input in a subsequent transaction. This was its key innovation and meant they didn't need to be tracked in the UTXO set. Data could be permanently recorded on the blockchain without burdening nodes' active memory.

The initial implementation was remarkably restrictive: one OP_RETURN output per transaction with a 40-byte data limit—barely enough for a cryptographic hash, let alone the "digital manifestos" some envisioned. Projects like Counterparty, building token systems on Bitcoin, immediately protested.  They had been using OP_CHECKMULTISIG as a hack to embed their data. Counterparty needed more room. Later that month, Jeff Garzik, a prominent Bitcoin contributor, waded into the Counterparty thread, guns blazing. "To date, I’ve not seen a blockchain data dumping scheme that could not be securely replaced with a simple hash," he declared. "You don’t need to store data in the blockchain. That is purely intellectual laziness." He lambasted Counterparty's use of OP_CHECKMULTISIG as an abuse, transactions "slipping through" because the protocol never expected such use.

The Counterparty devs shot back. They argued their data was being stored in the blockchain via these multisig outputs, and that the new 40-byte OP_RETURN limit was too small. It was so restrictive, they contended, that it inadvertently made their less-than-ideal multisig method more attractive.Luke-Jr, a mining pool operator and developer, echoed Garzik’s hard line: "The miners are supposed to filter out abuses." He argued that forcing data on non-consenting nodes was the core issue, and that 40 bytes was "more than sufficient for all legitimate needs for tying data to a transaction: you get 32 bytes for a hash, plus 8 bytes for some kind of unique identifier." He even revealed the original internal proposal for OP_RETURN had considered 80 bytes to accommodate 512-bit hashes, but this was ultimately deemed unnecessary by the Core team that settled on 40 for the release. True to his word, Luke-Jr’s mining pool began actively filtering out Counterparty transactions.

The Counterparty community felt the walls closing in. Fear and uncertainty spread like wildfire. If the OP_RETURN limit stayed at a measly 40 bytes and more miners followed Luke-Jr’s lead in filtering their existing OP_CHECKMULTISIG transactions, their project would be on life support.

A young Vitalik Buterin, then on the cusp of launching Ethereum, chimed in with a perspective that would echo through countless future Bitcoin debates: focus on the economics.

"In an ideal world, the concept of ‘abuse’ would not even exist; fees would be mandatory, and carefully structured to closely match the actual cost that a given transaction imposes on the network... If you can pay the fees for what you’re doing then you should be able to do it, no questions asked."

A simple, market-based philosophy that stood in stark contrast to the more prescriptive approach favored by some Bitcoin Core developers.Counterparty, scrambling, tried to adapt. On March 27th, they announced a change to their transaction format, desperate to circumvent Luke-Jr's mining filter. Luke’s response, delivered the next day, was swift and brutal: "Great news! Filter added to block this crap in less than 5 minutes, and 1 line of code." He likened Counterparty's actions to "forcing others to download/store your data against their free choice," arguing that full nodes had consented to store financial transactions, not "anything else."

The cultural clash was stark. Many Bitcoin developers, laser-focused on creating censorship-resistant digital cash, viewed these "meta-protocols" as parasitic. Dapp developers, on the other hand, were intrigued by Bitcoin's security and permissionless nature. However, this intense hostility and pessimistic view of using Bitcoin transaction data for alternative use cases played a major, if not decisive, role in pushing many Dapp developers towards alternative systems like Ethereum.

Finally, in May 2014, with Bitcoin Core 0.9.2, the OP_RETURN policy limit was officially nudged up to 80 bytes. Some saw this increase as a concession, a belated acknowledgment that 40 bytes was indeed too restrictive for legitimate uses like Counterparty's. It established the 80-byte standard that would last for over a decade.But the damage, culturally, had already been done. The first OP_Return War had drawn clear battle lines. A critical detail that would fester like a hidden wound remained: the 80-byte ceiling was just policy—a polite suggestion enforced by the dominant client. The actual consensus rules of Bitcoin allowed for far more. This gap between the polite request of policy and the hard reality of consensus would lie dormant for years.

4. Pandora’s Witness: SegWit Discount + Taproot (2021)

The quiet vow that OP_RETURN would keep the chain tidy lasted seven years. 2021 brought about the activation of the Taproot upgrade. Taproot was hailed as a leap forward for Bitcoin, promising enhanced privacy, smarter smart contracts through Tapscript, and leaner transactions. But woven in was the witness discount that would inadvertently fling open a new and cheap backdoor for arbitrary data.Segregated Witness (SegWit), the hard-won scaling solution of 2017, had already laid the groundwork. By separating signature data (the "witness") from the main transaction body, and by giving this witness data a hefty 75% discount on block weight (1 weight unit per byte versus 4 for non-witness data), SegWit had already subtly altered the economics of block space. Taproot, building on this, made it even more efficient and flexible to pack complex scripts into this discounted witness section.

Suddenly, the careful calculus that had made OP_RETURN a somewhat unattractive option for anything but the smallest data payloads was obsolete. Why bother meticulously squeezing your precious bytes into an 80-byte, full-freight OP_RETURN when you could effectively get four times the data for the same fee by tucking it away in the witness?

It took fourteen months for somebody to weaponise the loophole. In January 2023 Casey Rodarmor released Ordinals.  Ordinals assigned unique serial numbers to individual satoshis, effectively turning each one into a tiny, unique digital canvas. And onto these canvases, users could "inscribe" data – JPEGs, text files, whatever – by embedding it directly into the witness data of Taproot transactions. The witness discount was the key ingredient. Multi-megabyte files, like the 3.9MB "Taproot Wizard" JPEG, began appearing onchain, perfectly valid and relayable. The 80-byte OP_RETURN limit, once a battleground, now seemed like a footnote, a quaint restriction from a bygone era. The witness was the only game in town.

The numbers told the story: through 2023, between a third and nearly half of all transactions were inscriptions or their cousin BRC-20 token mints. Global mempools ballooned past 200 MB, fees spiked, and the old fear that block-space speculation would price out everyday payments crept back into Telegram chats and dev mailing lists. Witness data may be pruneable, but BRC-20 bookkeeping sprayed thousands of tiny spendable outputs across the ledger, fattening the UTXO set.

In early 2023, a subtle but significant change to the Bitcoin Core documentation for the -datacarriersize option further inflamed community tensions. Maintainers narrowed the definition of -datacarriersize—limiting it only to bytes inside an OP_RETURN scriptPubKey, not to data tucked in witnesses. Skeptics saw this redefinition as a convenient bit of linguistic jujitsu that allowed Core developers to argue that Ordinal inscriptions (which live in the witness, not the OP_RETURN scriptPubKey) weren't technically violating this particular policy setting. Whether this was a deliberate maneuver to sidestep the inscription "spam" debate or an innocent misunderstanding blown out of proportion, it became a symbol for those who felt Bitcoin Core was, at best, negligently passive, and at worst, actively complicit in what they saw as a fundamental attack on the network's integrity.

By the time Taproot celebrated its first birthday, the question Gavin Andersen had raised in 2010 was no longer hypothetical. The chain was filling with wizards, frogs, and tokens, all leveraging the witness discount that nobody in 2017 had recognized as a potential issue. The witness space battle was already lost. The next conflict would center on Bitcoin's remaining data constraint: the 80-byte OP_RETURN limit. And so the war drums started again.

5. The Non-Standard Underground Grows (2022-2024)

While the Ordinals gold rush was blasting JPEGs into the witness section, a quieter, more shadowy economy of data was already thriving in Bitcoin’s underbelly. This was the world of "non-standard" transactions – perfectly valid according to Bitcoin’s consensus rules, but frowned upon by the default Bitcoin Core client’s strict relay policies. The OP_RETURN limits were just one set of these policies. And as the years 2022 to 2024 unfolded, it became increasingly clear that these suggestions were being creatively interpreted by those with enough incentive and technical know-how.

This "non-standard underground" wasn't some secret cabal. No, it was an emergent property of Bitcoin’s design: miners maximize profit => users get creative. If the front door of the P2P network was too narrow, people found side entrances. Marathon Digital’s engineers were the first to package this logic into an API. Slipstream, launched in early ’23, let customers sidestep the public peer-to-peer network and send their hex straight to Marathon’s block templates. Got a transaction that Bitcoin Core’s default settings would turn its nose up at? Too big? Too many OP_RETURNs? Too weird in some other way? No problem. If it’s consensus-valid and you’re willing to pay the freight, Marathon would give it a look. This was the free market at work, a direct conduit to the block producers, bypassing the P2P network's self-imposed etiquette.

Then there was Peter Todd’s "Libre Relay" patchset. Todd, a long-time Bitcoin developer, maintained a set of modifications for Bitcoin Core. Nodes running Libre Relay would forward transactions that default Core nodes would drop, including those with oversized OP_RETURN payloads or multiple OP_RETURN outputs. This created a kind of overlay network, or a data-friendly P2P layer for those in the know. And it wasn't just these formal systems. Individual mining pools like F2Pool, Luxor Mining, TerraPool, EMCD, and ViaBTC were all caught slipping non-standard transactions into their blocks. Sometimes it was to help out a friendly project facing a technical jam, like MARA helping the RSK sidechain rescue 3,000 BTC stuck in a script with too many sig-ops. Sometimes it was pure Miner Extractable Value (MEV), like hoovering up fees from complex BRC-20 mints. And sometimes, it was just their own operational housekeeping – massive, zero-fee payout batches that no ordinary node would touch. If Core frowned, Libre shrugged.

The best public x-ray of this shadow market arrived in January 2024. An independent analyst, 0xB10C, published a forensic crawl of 117,000 blocks and catalogued every non-standard oddity miners had slipped through:

• Luxor’s 3.9 MB wizard jpeg was just the opening act; TerraPool followed with an 850 kB frog music video, F2Pool with an Assange magazine cover north of 990 kB.
• Scripts with two, three, five OP_RETURN outputs, all mined by F2Pool.
• 100-byte, 400-byte, 686-byte blobs. Again F2Pool, again via Libre.
• Pools consolidating coinbase dust, moving 3,900 BTC between their own addresses for zilch, or inserting on-chain Easter eggs (“you’ll run cln. and you’ll be happy”) just because they could.
• BRC-20 mint storms jammed 200-transaction trees into single blocks, blowing past Core’s 25-descendant mempool constraint without breaking a sweat.

The dossier’s takeaway was blunt: relay filters could somewhat shape the flow of transactions on the public P2P network. But they could not, and would not, stop determined, profit-seeking miners from including anything consensus-valid in their blocks if the price was right or the strategic imperative strong enough.

By 2025, data showed that nearly 5% of all block space contained transactions that standard Bitcoin Core nodes would never relay by default. Larger mining pools were receiving high-fee transactions through private channels, bypassing the public relay network and creating a competitive disadvantage for smaller miners - what theorists called "latency mining centralization."

This reality raised a critical question: if miners were already accepting transactions that ignored Core's relay policies, what purpose did the 80-byte OP_RETURN limit still serve, except to force developers into using worse technical workarounds? That brings us to the near present.

6. Roll-ups Knock: The Citrea Catalyst (Early 2025)

By early 2025, Bitcoin Layer 2 designs were brushing up against limits. At OP_Next and other dev-heavy conferences, early specs started circulating. Citrea was one of the more ambitious: a zero-knowledge rollup targeting full EVM compatibility, using Bitcoin as both data availability and settlement.

Citrea's model required routine commitments to the base layer for both normal operation and security fallback. Same for emerging BitVM variants: off-chain execution with onchain fraud proofs. These systems weren’t asking Bitcoin to be flexible. They were treating it as-is—slow, reliable, hard to censor—and were willing to build around that. The problem was that it required more room than Bitcoin Core’s default policies allowed.

The immediate constraint was OP_RETURN. Capped at 80 bytes since 2014, it was initially meant to prevent UTXO bloat by providing a prunable place to publish metadata. But Citrea’s challenge proofs—a SNARK verifying that a bridge claim was invalid—needed 144 bytes, minimum. This was the integrity check on whether coins could leave a bridge contract. If that proof didn’t land onchain, trust assumptions collapsed.Bitcoin Core's mempool filters any transactions that use OP_RETURN with more than 80 bytes, which makes propagation fragile and settlement timing unpredictable. As a result, rollup builders started reaching for workarounds by encoding the proof in a Taproot key path or other script path, unspendable by design, to get the data onchain. This data would now live forever in the UTXO set.

Which is precisely what OP_RETURN was supposed to prevent. To people deep in the mempool policy layer, this was a strong signal that the current policy incentivized worse outcomes.

Citrea’s engineer described the challenge flow as a rare, unhappy path. But the principle, the precedent, was the problem. As developer Steven Roose succinctly put it, the BitVM/Clementine use case was a clear trigger for the discussion.At that point, the 80-byte ceiling wasn’t protecting Bitcoin. It was forcing worse tradeoffs. L2s building proved not to be a fad and was here to stay. The constraints that made sense in 2014 no longer aligned with how developers used the system.

7. Tribal Pull Requests Warfare (May 2025)

If Citrea was the trigger, Antoine Poinsot’s mailing-list post to relax OP_RETURN limits was the primer, and Peter Todd’s PR #32359 was the detonation.

In April 2025, the OP_RETURN conversation reopened. Bitcoin’s consensus rules define what is valid. Standardness rules define what the dominant client (Bitcoin Core) will relay and accept into its mempool. The rules around OP_RETURN are standardness policies, capped at 80 bytes, one output per transaction. They’re not enforced by miners or consensus. They determine what propagates through the default peer-to-peer network. However, since most of the network runs Core, policy effectively shapes what’s viable in practice.

On April 17, 2025, Antoine Poinsot proposed relaxing these OP_RETURN limits. His argument was direct: current policy pushed otherwise valid and useful protocols, like Citrea, into worse alternatives. The original rationale behind OP_RETURN was to avoid that exact problem.

Ten days later, Peter Todd opened PR #32359 on Bitcoin Core’s GitHub: “Remove arbitrary limits on OP_Return (datacarrier) outputs.” The proposal dropped both the size limit and the restriction on the number of OP_RETURN outputs. More controversially, it removed user configuration options like -datacarrier and -datacarriersize, which let node operators set local policy. Todd had made a similar proposal two years earlier. He closed it at the time due to a lack of momentum. This time, he reopened it at Poinsot’s request.

PR #32359 became an instant lightning rod. The GitHub thread exploded with hundreds of comments. The "Concept NACKs" (No Acknowledgement, signaling fundamental disagreement) poured in from developers and community members led by Luke Dashjr. At this stage, the primary objections often centered on removing user choice and the philosophical implications of uncapping data limits like spam.

Recognizing the fierce pushback, particularly on removing configuration options, a second, more nuanced proposal quickly emerged in early May. PR #32406, titled "policy: uncap datacarrier by default," was opened by instagibbs, another Bitcoin Core contributor. This PR also proposed uncapping the OP_RETURN size and allowing multiple outputs by default. However, it retained the -datacarrier and -datacarriersize arguments, but marked them as deprecated. The idea was that if a user did set -datacarriersize, that value would be treated as a "budget" to be spread across all OP_RETURN outputs in a transaction. Some saw this as a more palatable way to achieve policy change while offering a transition path for user configuration. PR #32359 was subsequently closed, and #32406 became the main venue of discussion.

The proponents of uncapping (or significantly relaxing) the limits, a diverse group including Poinsot, Todd, Sjors Provoost, Pieter Wuille, Greg Maxwell, Andrew Chow, "instagibbs," Murch, Gloria Zhao, Jameson Lopp, Erik De Smedt, Steven Roose, and many GitHub reviewers, coalesced around several key arguments:

• Harm Reduction (The Big One): This was the banner under which most proponents marched. The existing 80-byte OP_RETURN limit, they argued, was forcing legitimate use cases that required their data to be in transaction outputs and relayed via the public P2P network, into using far more harmful methods. The main culprit cited was embedding data in "fake pubkeys" – outputs that looked spendable but were designed to be unspendable, permanently bloating the UTXO set. Uncapping OP_RETURN would allow this data to live in a prunable, UTXO-friendly space. As Rob Hamilton put it on GitHub, it was "Better to have provable unspendable outputs than dust outputs forever in the utxo set." Poinsot stressed this was about applications that need to store data in outputs and use the public relay network, not about competing with witness data for large JPEGs.
• Aligning Relay Policy with Mining Reality (The Pragmatic Play): A powerful technical argument, championed by Greg Maxwell and Pieter Wuille, was that default relay policy should not be significantly stricter than what miners are actually willing to include in blocks. The 0xB10C study and anecdotal evidence showed that miners (especially large ones like F2Pool, or those with direct submission channels like MARA's Slipstream) were already including oversized or multiple OP_RETURN transactions if the price was right. This disconnect between node policy and miner behavior, they argued, led to several ills:
  • Direct-to-Miner Submission & Centralization: It incentivized users to bypass the P2P network and send non-standard transactions directly to miners, favoring large, well-connected mining pools and increasing mining centralization.
  • Impaired Block Propagation: If nodes didn't have transactions that ended up in blocks (because they were filtered by local policy but accepted by miners), compact block relay became less efficient, slowing down block propagation across the network. This disproportionately hurt smaller miners and could also lead to centralization.
  • Inaccurate Fee Estimation: Mempools that didn't reflect the true landscape of transactions miners were considering made fee estimation less reliable. Uncapping OP_RETURN was thus framed as a move to improve network health and decentralization by making the public mempool a more accurate reflection of reality.
• Ineffectiveness of Current Limits as a Deterrent: Proponents argued the 80-byte "nudge" was simply no longer working. Determined users or protocols needing more space were finding ways around it, often in more harmful ways.
• Aid to Layer 2 Engineering: Providing a more capacious, standard, and prunable way for L2 solutions to anchor essential data onchain is crucial for Bitcoin's future scalability and utility.
• Code Simplification: Eventually removing arbitrary limits and their associated configuration options would simplify the Bitcoin Core codebase and reduce the maintenance and testing burden for what proponents saw as ineffective policies.

The anti-uncapping camp (the "Filter Faction"), which included prominent voices like Luke Dashjr, raised a host of counterarguments, often rooted in a more conservative or purist vision of Bitcoin:

• Bitcoin is Money, Data is Mission Creep: The most fundamental objection was philosophical. Bitcoin, they argued, is peer-to-peer electronic cash. Its primary, if not sole, purpose is monetary. Allowing larger arbitrary data payloads, even in the prunable OP_RETURN, was seen as a dangerous "mission drift," an endorsement of non-financial uses that would dilute Bitcoin's core value proposition and potentially turn it into a "general-purpose database" or an "Ethereum-style shitcoin thing."
• Opening the Floodgates to "Spam": A pervasive fear was that uncapping OP_RETURN would unleash a new wave of "spam" – JPEGs, memes, arbitrary text, perhaps even illicit content onchain. This would, they feared, increase blockchain bloat, drive up transaction fees for legitimate financial users, and strain the resources of full node operators, potentially harming decentralization if running a node became too expensive.
• Core Developer "Capture" & Disregard for Community: Accusations and suspicions about the motivations behind the proposal were rife. Some suggested developers were compromised, co-opted by VC roll-up interests (with Citrea often singled out), or were pushing a personal agenda against the wishes of the broader community.
• Loss of Node Operator Autonomy (The -datacarriersize Fight): The proposal in PR #32359 to remove the -datacarrier and -datacarriersize configuration options was a major sticking point. Many node operators,  felt this stripped them of their sovereign right to define their own node's relay policy and protect their mempool from what they considered undesirable data. Users wanted the control even if the option was a "placebo" against what miners ultimately included.
• Filters Can Work; Bitcoin Needs Stricter Enforcement: The "filter faction," often associated with Luke Dashjr and users of his Bitcoin Knots client, argued that standardness rules should be used to actively filter "spam." They believed that Bitcoin Core had erred in not being more aggressive in filtering inscriptions (e.g., by not merging Luke's earlier PR #28408) and that the solution was more and better filters, not fewer.
• Unintended Consequences & New Attack Vectors: Some worried that creating larger, easily accessible data lanes, even if prunable, could introduce new, unforeseen attack vectors or exacerbate existing ones, like mempool spamming or resource exhaustion attacks on nodes.

The stage was set. The second OP_RETURN war was in full swing.

8. The War Winds Down: Knobs, Knots & the Poinsot Doctrine

For ten years, Bitcoin Knots had been little more than Luke Dashjr’s personal fork of Core. A one-man tree where he merged upstream releases, grafted on his own spam filters, and shipped code only after it passed the “Luke test.” Most users barely noticed it existed; most contributors never opened a pull-request because there was only one reviewer – Luke himself.

That changed the moment #32359 hit GitHub.

• Early April: Knots counted a couple hundred public nodes – well under 1 % of the reachable network.
• May 12: Coin.Dance’s crawler flashed ≈1 400 Knots nodes out of 21 300 total, nudging 7 %.
• Mid-May peak: other crawlers briefly logged ~9 % as operators flipped their Raspberry Pis from /Satoshi to /Knots.

That jump sounded small – until you looked at Core’s contributor graph. Core has 350 + people with merged commits since 2020, half a dozen paid maintainers, a CI farm, and a six-month release cadence. Knots has one maintainer, three years of unreviewed backlog, and a last-tagged release from 2022-05-25. Yet in two weeks it had captured a node share bigger than btcd, bcoin, Bitcore, and every other alt-implementation combined.

Why?

• Symbolic veto. Setting datacarrier=0 in Knots was a middle-finger to #32406 without touching Core’s codebase.
• Hard filters baked-in. Luke’s build still blocks inscriptions, multi-OP_RETURN payloads, and the Taproot Wizard JPEG – policies the filter faction wanted but Core refused to ship.
• Easy migration. Switching binaries left wallet files, chains, and indexes untouched; a five-minute docker swap felt lower-risk than compiling Libre Relay patches or lobbying miners.

To be clear, Knots is not a long-term alternative to Core’s engineering pipeline. It is a protest vote. But the  existence of a 7- 9 % enclave proved two things:

1. Node diversity is trivially achievable when a controversy touches mempool policy rather than consensus – you just change what you relay.
2. The “sovereign mempool” narrative still resonates. A non-trivial slice of operators would rather outsource maintenance to a single opinionated coder than accept defaults they see as permissive.

On the Core side, the counter-move was knobs—or, more precisely, leaving the knobs in place. Instagibbs’ PR #32406 kept -datacarrier and -datacarriersize, stamped them deprecated, and then set the default to “no ceiling.” If you wanted to slam the door back to 83 bytes you still could; you just had to turn the wrench yourself. That single design choice robbed the opposition of its sharpest talking point—forced uniformity—without compromising the larger goal of harm-reduction.Antoine Poinsot published a rebuttal to defuse the protest. His core points:

• The change was about harm reduction for a specific existing problem (L2s needing output-based data being forced into UTXO-bloating workarounds because of the 80-byte limit on publicly relayed OP_RETURNs).
• It was not about enabling large-scale data storage (witness data is 4x cheaper and already the method of choice for that).
• It was not about "caving to spammers" (the L2 use case is legitimate, and actual "spam" will use the cheapest available method anyway).
• The existing 80-byte limit was ineffective as a general deterrent for those willing to use private relays or non-standard outputs.
• Keeping the -datacarrier option, once the default is uncapped, provides no real network benefit and could be a "footgun" for users.
• Accusations of ulterior motives or developer capture were unfounded and a distraction from the technical merits.

Those arguments convinced most maintainers. #32359 was closed; #32406 – the compromise that leaves the knob but prints “deprecated” – is still live, still gathering ACKs, and likely to land in v30. If it does, Knots users will face a choice: stay on a codebase whose last upstream merge predates tap-sync improvements, or accept Core’s larger, prunable OP_RETURNs.

Bottom line: The OP_RETURN war ends not with a knockout but with a controlled refactor. Core’s relay policy adapts to the economic facts on the ground; Knots offers a principled dissenting build; and Poinsot’s harm-reduction mantra—“If the data’s coming anyway, let’s store it where it hurts least”—becomes the new default wisdom.

9. Technical Reality Check

As the OP_RETURN debates spilled across GitHub, podcasts, mailing lists, and Twitter, many of the loudest arguments strayed into culture‑war proxies, smoke grenades, or mischaracterizations born from half‑remembered blog posts. Below is a surgical pass through the most significant claims that shaped the discussion, and how they stand up to technical scrutiny.

12. Final Take: The Case for a Bigger OP_RETURN

Bitcoin’s strength isn’t that it prevents weird ideas. It’s that it gives them a price.The history of OP_RETURN is a story of backpressure. It began capped—80 bytes, a placeholder size, chosen in 2014 when colored coins were still a novelty and the idea of verifiable off-chain computation hadn’t yet matured. At the time, the cap was a hedge against unknowns. But over time, the system evolved, while that limit didn’t.

The market constantly re-prices what “garbage” is worth.  So developers adapted...badly. With OP_RETURN too constrained to carry the data they needed, they resorted to workarounds: encoding payloads into fake multisig outputs, or misusing Taproot key paths. The result: permanent entries in the UTXO set that cost every full node disk, RAM, and CPU. There’s no expiration date on misuse. If it enters the UTXO, it stays. The irony is that the very thing the cap tried to prevent—bloat, inefficiency, spam—was exactly what it encouraged. By making the honest path artificially narrow, it incentivized abuse of the parts of Bitcoin that were meant to be compact and durable.

Pull request #32406 doesn’t legalize spam. It doesn’t favor NFTs. It doesn’t even make data storage cheaper. In fact, storing data in OP_RETURN is more expensive per byte than embedding it in witness space. JPEGs won’t move there. They’d be dumb to. The point of the proposal isn’t to attract more data, it’s to direct the data we already have into the one channel that can be pruned.

That’s the technical case. Smaller UTXO. Simpler audits. Better fee signals.

But that’s not why people are angry.

Critics call it a conspiracy. They say Core developers have been compromised. That this is a covert effort by spam apologists to destroy Bitcoin from within. And yet: this change benefits no single group. JPEGs already go through witness space. Inscribers don’t want OP_RETURN. They already bypass it. This isn’t a gift to anyone. It’s a defensive measure against bloat, and a cleanup for a client that’s been patched over too many times.It’s a minor to moderate optimization. But it opens a major door.

The critics miss this: nearly every useful extension to Bitcoin—tokens, stablecoins, sidechains, rollups—began life as spam in someone’s eyes. Colored coins were dismissed. Ordinals were laughed at. Today, those primitives support real protocols. Their descendants anchor multi-billion dollar systems.

A bigger OP_RETURN gives new use cases room to grow—while making sure they pay a premium to do it. And in the meantime, it protects the network from their worst side effects.

The bigger picture is this: if Bitcoin is to become the root ledger for multiple financial layers, if L2s are to succeed, if cross-chain proofs and timestamping are to become routine, we can’t afford to keep hiding useful behavior behind hacks. The market will continue to push data onchain. It would be better to route that through a clean, discardable, auditable path than pretend it isn’t happening.

The future won’t care what some Bitcoiners once thought was spam. It will only care whether the infrastructure is ready to handle what comes next.

Uncapping OP_RETURN is investing in architecture. And architecture that leaves room for new ideas is how Bitcoin wins.

If there's a topic you’d like us to cover or have questions, reach out at [email protected].