The 100,000-Byte Blank Check: Bitcoin Core v30, OP_RETURN, and the Knots Rebellion

1. Eighty-Three Bytes of Truce

For years, Bitcoin Core's default policy would relay and mine a transaction carrying at most 83 bytes of OP_RETURN data in one data-carrier output. OP_RETURN marks attached data as provably unspendable; the ceiling and single-output rule were standardness defaults, not block-validity rules.^[1][11]

The rule was never consensus. Bitcoin Core defines mempool, or transaction relay, policy as validation rules applied in addition to consensus to unconfirmed transactions before mempool admission. Those rules are local, configurable, and explicitly not applied to transactions in blocks. A transaction one node calls nonstandard can still be mined by a willing miner, and relay acceptance is not endorsement.^[8]

The data-policy dispute predated 2025: the #32406 thread referenced an earlier inscription-filtering proposal that had not been merged. In April 2025 the argument reopened on bitcoin-dev, where developers debated increasing or removing the default OP_RETURN size limit.^[3][10]

2. The Mailing List Fills Up

The thread grew so voluminous that Bitcoin Optech's 2025-05-02 newsletter declined to summarize it fully and instead presented what it considered the most compelling argument for and against the change.^[10]

For lifting the limit, Pieter Wuille argued that standardness policy is unlikely to significantly prevent confirmation of data-carrying transactions created by well-funded organizations, which can deliver transactions directly to miners; he also argued that blocks are generally full with or without data-carrying transactions, so the overall amount of data a node must store is roughly the same either way.^[10]

Against it, Jason Hughes argued that a higher limit would make it easier to store arbitrary data on the computers running full nodes, and that some of that data could be highly objectionable — including material illegal in most jurisdictions — regardless of whether the node encrypts its storage.^[10]

On 2025-04-27, Peter Todd turned the debate into a pull request. Numbered #32359 and titled "Remove arbitrary limits on OP_Return (datacarrier) outputs," it proposed deleting the limits and the -datacarrier options entirely, reasoning that they were already bypassed by direct submission to miner mempools such as MARA's Slipstream and by non-enforcing forks like Libre Relay. The pull request closed unmerged on 2025-05-12, but its premise survived in a softer successor.^[9]

3. Concept NACK: The Thread Erupts

On 2025-05-02, Bitcoin Core contributor Gregory Sanders opened pull request #32406, "policy: uncap datacarrier by default." It raised the default -datacarriersize so a transaction could carry up to 100,000 bytes of OP_RETURN data — effectively the maximum transaction size — permitted multiple OP_RETURN outputs per transaction by default, and kept the -datacarrier options alive only as deprecated settings.^[3][11]

The review thread became a battlefield of Concept ACKs and Concept NACKs. A maintainer invoked repository moderation guidelines—discuss the patch, not Bitcoin in general; critique ideas, not motives—because the repository is not a general Bitcoin forum. The sharpest rejection came from Bitcoin Knots maintainer Luke Dashjr:^[3][5]

Concept NACK. Already been over this on multiple PRs. Spamming it with immaterial minor differences won't change the fundamental insanity and malice of the concept.^[5]

— Luke Dashjr

Sanders, the pull request's author, refused to treat the old limit as load-bearing infrastructure. When one commenter argued that data-carrier limits exist mainly to protect the peer-to-peer and mempool layers, his reply was blunt:^[4]

Simply not true. The only motivation for the rule is to nudge people to not store arbitrary data on chain when it can be avoided.^[4]

— Gregory Sanders

4. Two Clients, Opposite Defaults

Pull request #32406 was merged on 2025-06-09. Bitcoin Optech's summary recorded the essentials: the default -datacarriersize setting rose from 83 to 100,000 bytes — the maximum transaction size limit — the one-OP_RETURN-output-per-transaction restriction was lifted, the size limit became an allowance allocated across all such outputs in a transaction, and the -datacarrier options remained only as deprecated settings expected to be removed in some future release.^[3][11]

On 2025-10-13, Bitcoin Core version 30.0 shipped with the new policy in its release notes: -datacarriersize is increased to 100,000 by default, which effectively uncaps the limit because the maximum transaction size will be hit first, and it can be overridden with -datacarriersize=83 to restore the old behavior. Multiple data carrier outputs, the notes state, are now permitted for relay and mining, with the limit applied across all such outputs in a transaction.^[1][2]

The cited Bitcoin Knots v28.1 code already carried opposite defaults. Its policy header caps OP_RETURN at 42 bytes—40 bytes of data plus opcode overhead—and enables full counting across known data-carrier methods. Its initialization code exposes -datacarriercost for extra mempool weight and a -corepolicy switch that soft-sets Core-like values, including -datacarriersize=83.^[12][7]

The two clients therefore offered different local policies without changing consensus. Peter Todd, whose broader proposal had closed weeks earlier, told remaining objectors that an alternative implementation was available:^[3][6]

Here, we have good consensus among reasonable devs that actively contribute to Bitcoin Core that this change is a good idea. Secondly, the people who still disagree with this change are welcome to run an alternative fork such as Knots.^[6]

— Peter Todd

5. The War Nobody Could Win

What the war never touched was consensus. No validity rule changed in either client: relay and mining policy remained local, configurable settings, applied to unconfirmed transactions and never to block validation, so a transaction rejected as nonstandard by a default node could still be mined by any miner that accepted it. Accepting data for relay also never meant endorsing it — a mempool is a staging area, not the ledger.^[1][8]

Nor did the labels settle anything. "Spam" and "censorship" stayed positions in an argument, not findings: Optech chose to publish the most compelling arguments on each side rather than adjudicate, and the bypass economics behind PR #32359 — direct-to-miner submission through services like MARA's Slipstream — meant defaults were suggestions to well-funded senders, not walls.^[9][10]

The dispute left a market of defaults. Commenters claimed a migration from Core to Knots, but the thread supplied no settled metric. The cited releases encoded opposite answers—100,000 bytes in Core 30.0 and 42 bytes in Knots v28.1—so operators could express a preference through the software and settings they ran. That is governance by node choice rather than decree.^[3][12]