A deep research report examining whether the "technical explanations" for removing Bitcoin's 80-byte OP_RETURN limit constitute gaslighting—as Luke Dashjr claims.
The story of OP_RETURN is a story of incremental normalization—each step making the next seem inevitable.
Bitcoin Core 0.9.0 adds OP_RETURN with a 40-byte limit as harm reduction—a prunable output type so data embedders stop polluting the UTXO set.
After community discussion, the limit is raised. Nine months without catastrophe was cited.
Peter Todd opens PR #28130 to remove OP_RETURN limits. Rejected by the community.
Antoine Poinsot (Chaincode Labs) asks Todd to reopen as PR #32359—after learning that Citrea (a VC-funded ZK-rollup) needed more than 80 bytes.
PR #32359 receives 423 thumbs-down vs 105 thumbs-up on GitHub. Critics are muted.
GitHub moderators mute Luke Dashjr and Bitcoin Mechanic from the discussion.
PR #32406 merged by Gloria Zhao despite vocal opposition. Limit raised to 100,000 bytes.
Core plans to deprecate user configurability of datacarriersize—forcing the new defaults.
Breaks 5-year silence: "I strongly recommend not upgrading to Core v30."
Ava Chow reverses deprecation plan hours before v30 release after community backlash.
Bitcoin Core v30 ships with 100KB OP_RETURN limit. User configuration preserved (for now).
Bitcoin Knots adoption surges from ~2-4% to ~21% of all nodes—an 850% increase.
Bitcoin Core removes Luke Dashjr's DNS seed. Gloria Zhao resigns as maintainer.
Community-driven temporary soft fork proposal begins miner signaling.
Each argument presented by Wuille, Todd, BitMEX Research, reardencode, Murch, and Adam Back follows the same pattern: a superficially reasonable claim that collapses under scrutiny.
Data can be stored via witness data, bare multisig, fake pubkeys, or direct miner submission (MARA Slipstream). The limit is "mere discouragement." — Wuille, Todd, Poinsot, BitMEX Research
Circular reasoning: "Miners will mine spam anyway" assumes the conclusion to justify the premise. Relay policy directly shapes what appears in mempools that miners see.
The data says otherwise: Chris Guida demonstrated a 99% reduction in large OP_RETURNs when filters were active—proving they work as meaningful discouragement.
Self-created bypass: Peter Todd's own "Libre Relay" software is a primary bypass tool. He then cites his own tool's existence as proof that limits don't work. This is like setting a fire and arguing fire departments are useless.
False equivalence: Data in witness fields requires specialized tools to reconstruct. OP_RETURN data is immediately readable via standard APIs. It's the difference between hiding a note in your wall and posting it on your front door.
Without OP_RETURN, data embedders use UTXO-polluting methods that permanently bloat the UTXO set. OP_RETURN is prunable and therefore preferable. — Todd, Wuille, Lopp
False dilemma: The options aren't "unlimited OP_RETURN" or "UTXO pollution." The option is: maintain reasonable limits while fixing specific bypass methods.
Purpose shift: OP_RETURN was introduced for small metadata (40-80 bytes). Expanding to 100KB fundamentally transforms it from a hash anchor into a data highway.
Luke's alternative: UTXO pollution via fake addresses can be addressed through address format changes without consensus modifications—a surgical fix vs. opening the floodgates.
Cost asymmetry (Nick Szabo): Miners profit from fees. Node operators absorb storage/bandwidth costs indefinitely without compensation. Making data storage easier worsens this already unfair burden.
If relay policy filters transactions, miners who accept them directly gain competitive advantage, leading to centralized submission pipelines. — Wuille, reardencode
Zero evidence: The 80-byte limit operated for a decade without causing mining centralization. Chris Guida asked: what evidence supports this claimed danger after the filter "spent a decade minding its own business"?
The opposite is true: Making Bitcoin data-friendly attracts well-funded corporate users (Citrea, Chainway) who build direct-to-miner infrastructure regardless. MARA Slipstream exists for premium revenue, not because of OP_RETURN limits.
Convenient reversal: Wuille acknowledged he was a "strong proponent of OP_RETURN limits in the past." His reversal aligns with ecosystem interests rather than any new technical discovery.
Relay policy is voluntary. Nodes choose what to relay. It's not censorship. — Wuille, Todd, Zhao
Defaults define reality. In software, defaults determine behavior for 95%+ of users. Changing the default from "filter large data" to "accept everything" is a radical policy shift disguised as a technical tweak.
Self-contradictory: They simultaneously argue the limit is "just policy" (trivial) AND that removing it is crucial to prevent mining centralization (critical). It can't be both.
Bitcoin Core shouldn't make value judgments about what transactions are "legitimate." — Zhao, Back, Poinsot
Bitcoin has always made such judgments. Standardness rules ARE value judgments—about transaction sizes, output types, script complexity, dust limits. Every standardness rule is a judgment about network health.
Selective neutrality: Removing ONE specific limit while keeping all others is itself a value judgment—that data storage deserves special treatment.
"It would be an accident waiting to happen." — Satoshi Nakamoto, on blockchain data storage
The pattern of behavior matches classic gaslighting tactics:
The same arguments are presented through YouTube panels, Stacker News, X threads, Delving Bitcoin—creating the illusion of overwhelming expert agreement. Listing the same argument made by different people treats quantity as quality.
"Actual technical/coding experts" have explained it, therefore disagreeing means you're "ignorant" or "acting dumb." This dismisses legitimate concerns by attacking questioners' competence rather than addressing arguments.
The change was framed as a minor "standardness policy adjustment" rather than what it was: a fundamental shift in Bitcoin's relationship to data storage. By controlling the framing, proponents avoided discussing real implications.
When arguments failed, moderators muted prominent critics (Luke Dashjr, Bitcoin Mechanic) from the GitHub discussion. Giacomo Zucco called them "absolutely out-of-control"—a "cabal of self-appointed politicians."
Ava Chow (Dec 2023): "If it is controversial, we don't touch it." The PR got 423 against vs 105 for. Yet it was merged anyway, and later restoration attempts were rejected as "settled."
Knots users called "Knotzis" (Knots + Nazis). Fabricated "hit piece" against Luke alleging a hard fork. His DNS seed removed from Core. Personal attacks on those who disagreed.
The "Citrea problem" (needing >80 bytes for ZK-rollup data) was presented as requiring an urgent universal solution. In reality, Citrea is one VC-funded company whose business model benefits from cheap on-chain data.
Follow the money.
| Person / Entity | Role | Conflict |
|---|---|---|
| Jameson Lopp | Vocal PR #32359 supporter | Investor in Citrea — which directly benefits from larger OP_RETURN |
| Antoine Poinsot | Initiated the reopened PR | Chaincode Labs employee; triggered by Citrea's data needs |
| Peter Todd | PR #32359 author | Creator of Libre Relay — the bypass tool he cites as proof limits fail |
| Citrea / Chainway | ZK-rollup project | VC-funded company needing cheap on-chain data storage |
"If you are really such a talented developer, then how come you are completely incapable of convincing people that your changes are good?" — Samson Mow (JAN3)
"Bitcoin Core developers were colluding with Citrea to include spam in bitcoin's blockchain." — Ocean Mining (Bitcoin Mechanic)
Bitcoin Core's stated standard: controversial changes require "rough consensus." By every measurable metric, this change had none.
Ava Chow (December 2023): "If it is controversial, then we don't touch it."
Gloria Zhao (June 2025): Merges the controversial change anyway.
Ava Chow (Later 2025): Rejects PR #34214 to restore limits because the debate is "settled."
The standard changed depending on which side it served.
"Bitcoin Core developers are about to merge a change that turns Bitcoin into a worthless altcoin, and no one seems to care to do anything about it." — Jason Hughes (Ocean Mining)
The irony of censoring developers on a project built around censorship resistance was not lost on the community.
"Absolutely out-of-control—a cabal of self-appointed politicians." — Giacomo Zucco, on GitHub moderators
"Antithetical to the ethos of Bitcoin." — Michelle Weekley, on the censorship
BIP-110 (originally BIP-444) is the community's technical counter-offensive. It's a temporary one-year soft fork restricting arbitrary data storage.
"I strongly recommend not upgrading to Core v30." Warned of asymmetric costs and legal liability for node operators.
Called it "utter insanity." Led the technical resistance through Knots and BIP-110.
"If you are really such a talented developer, then how come you are completely incapable of convincing people that your changes are good?"
Criticized "fiat politics" logic—pretending distinctions don't exist to avoid making value judgments.
Called GitHub moderators "absolutely out-of-control" and a "cabal of self-appointed politicians."
"Bitcoin Core developers are about to merge a change that turns Bitcoin into a worthless altcoin."
Mining centralization argument. Reversed his own decade-long support for limits without citing new evidence.
Created the bypass tool, then cited its existence as proof limits are ineffective.
"This isn't new"—ignoring the scale change from 80 bytes to 100,000 bytes.
"They will find a way...we should ask what the preferred means is."
Examining the specific sources listed in the original post claiming the "technical reasons" are clear:
Several sources listed as explaining "why it was removed" actually argue against the removal or warn about consequences. The list conflates "explaining the pro-removal argument" with "endorsing the pro-removal argument."
| Source | Actual Argument | Fatal Flaw |
|---|---|---|
| BitMEX Research | "Bypass" argument dominates | Does not address circular reasoning or 99% filter effectiveness |
| reardencode | Standardness policy argument | Does not address decade of stability or filter effectiveness data |
| Murch | Multiple OP_RETURN outputs for "consistency" | Does not address node operator cost asymmetry |
| Adam Back | "This isn't new" | False equivalence: what miners can do vs. what defaults encourage |
| Pieter Wuille | Mining centralization via out-of-band submission | Unfalsifiable claim; reversed own decade-long position without new evidence |
Sources listed as showing "why BIP-110 is dangerous" are more nuanced than presented:
| Source | Actual Position |
|---|---|
| Giacomo Zucco | Actually supports limiting data; concerns about BIP-110 are implementation details, not philosophy |
| theonevortex | Concerns about BIP-110 risks while opposing OP_RETURN expansion |
| Tone Vays | His own presentations argue AGAINST the limit removal |
Bitcoin Core developers argued they were defending "censorship resistance" by removing transaction filters. Yet they:
Using self-created bypasses as evidence that limits don't work
Treating 80 bytes and 100,000 bytes as a mere "policy adjustment"
Key proponents have financial stakes in Citrea and data-storage use cases
Merging despite 4:1 community opposition and their own "no controversial changes" standard
Muting critics on GitHub while claiming to defend "censorship resistance"
Repeating the same arguments through multiple channels with coordinated media coverage
"Knotzis" label, fabricated hit piece against Luke, DNS seed removal
First "just policy," then "crucial for preventing centralization," then "already settled"
When someone says the reasons have been explained "SOOO MANY times," they're correct that the arguments have been repeated many times. But repetition does not equal validity.
The arguments contain fundamental logical flaws (circular reasoning, false equivalences, unfalsifiable claims) and are advanced by people with direct financial conflicts of interest, using a process that violated Bitcoin Core's own governance standards while censoring critics.
That's not "explaining." That's gaslighting.