Samson Mow says the blowback around BIP-110 was not random at all. In his view, Bitcoin Core’s handling of the OP_RETURN fight helped create the exact backlash it later got.
- Mow blames Core behavior: He says hostility and messy politics helped fuel the reaction.
- OP_RETURN is the flashpoint: The dispute is about whether Bitcoin should carry arbitrary data on-chain.
- BIP-110 is a consensus soft fork: It aims to restrict several data-bearing fields, not just tweak relay policy.
- The real fight is philosophical: Bitcoin as money first, or Bitcoin as a broader data layer with limits.
In exchanges on X involving Michael Sullivan, Antoine Poinsot, and Adam Back, the Bitcoin entrepreneur said the opposition should have seen the backlash coming.
“If you don't take responsibility for your own hand in directly spawning the BIP-110 movement, it will just happen again, ”
He also accused the other side of coming in just as hard as the people they were criticizing.
“Your ‘side’ was just as nasty in its attacks, especially given you and other Core devs' close association with angry vitriol-spewing people like Brian from Bitcoin Magazine, ”
“Did you really not expect that anger and vitriol to be returned tenfold?”
That is not subtle language. Then again, Bitcoin governance fights rarely are. The same people who say they are defending neutrality often act like they own the moral high ground, which is usually where the shouting starts.
To see why this matters, the technical basics need to be clear.
OP_RETURN is a Bitcoin Wiki transaction field that can be used to embed arbitrary data, meaning text or binary data that does not transfer bitcoin. Supporters of restrictions argue that Bitcoin’s scarce block space should be reserved mainly for monetary transactions, not as a junk drawer for every data experiment and vanity project under the sun.
BIP-110, titled Reduced Data Temporary Softfork, is a real Bitcoin consensus soft fork proposal. According to the BIP text on GitHub, it is meant to temporarily limit the size of data fields at the consensus level and restore the 83-byte OP_RETURN policy limit. The proposal is framed as a way to “refocus priorities on improving Bitcoin as money.”
That distinction between policy and consensus is not a minor detail. A default policy setting affects how software relays or prefers transactions. A consensus rule changes what the network actually accepts as valid. Mow leaned hard on that difference, arguing the OP_RETURN fight had been blown out of proportion by people treating a default as if it were the end of the world.
“Everyone knew it was only a default, which is exactly the point: changing it or not changing it made no practical difference, ”
That is his interpretation, not a neutral law of nature. The BIP-110 authors clearly disagree, or they would not be trying to push enforcement into consensus in the first place.
The proposal is broader than just OP_RETURN, too. The BIP text says it would restrict several ways of embedding data, including oversized scriptPubKeys, large OP_PUSHDATA payloads, some witness items, and certain Taproot-related structures. It also presents the change as temporary, describing it as a one-year deployment with grandfathering for UTXOs created before activation so old coins would not be trapped by the new rules.
In plain English: this is not a small software preference tweak. It is a serious attempt to use Bitcoin’s rules to push the network back toward a narrower monetary role.
The BIP itself makes that ideological stance explicit. It argues that arbitrary data storage creates negative externalities, burdens node operators, and distorts incentives away from Bitcoin’s intended function as money. That is the pro-restriction case in a nutshell: keep the chain lean, keep costs down, and stop normalizing non-monetary clutter on scarce block space.
There is a counterpoint, though, and it is not nonsense. Bitcoin has long been used for more than simple payments, whether people like that or not. Some data-anchoring use cases are clumsy, some are self-serving, and some are arguably useful. The hard part is deciding where “legitimate use” ends and “network abuse” begins without turning protocol policy into a permanent faction war.
Mow says the backlash around BIP-110 could have been avoided if people had stepped back instead of escalating things.
“All I did was hint at structural problems within Core, problems Jon Atack later discussed openly, ”
He also referenced what he called the “Zhao/Newberry improprieties” and “a long list of other clumsy, guilty-looking missteps.” Those references were not explained further in the material available here, so they should be treated as his allegations, not as settled fact.
That matters because Bitcoin drama has a habit of mixing hard technical questions with half-formed accusations, ego, and tribal loyalty. Once that happens, people stop arguing about code and start arguing about motives. That is usually where the nonsense meter pegs out.
The research materials also note that the pro-restriction view has already helped drive the creation of a new Bitcoin fork that later failed because adoption was extremely low. No name or supporting details were provided, so that point should be treated cautiously. The broader lesson, though, is old and boring and still true: forks are easy to announce and hard to make matter. Code is cheap. Economic gravity is not.
What BIP-110 shows most clearly is that this fight is not only about bytes, limits, or transaction formats. It is about what Bitcoin is for. One side wants a money-first settlement network with strict guardrails around data use. The other side worries that overreach, even in the name of purity, can turn the protocol brittle and overly politicized.
That tension is not going away. Bitcoin’s block space is scarce, and scarcity forces ugly choices. Every limit picks winners and losers, and every rule change becomes a referendum on Bitcoin’s identity. That is why the OP_RETURN debate keeps coming back: it is never really just about OP_RETURN.
Key questions and takeaways
-
What is BIP-110?
It is a Bitcoin consensus soft fork proposal called Reduced Data Temporary Softfork. According to the BIP text on GitHub, it would temporarily limit several data-bearing fields and restore the 83-byte OP_RETURN policy limit. -
Why is OP_RETURN such a flashpoint?
OP_RETURN lets users embed arbitrary data in Bitcoin transactions. Supporters of restrictions say Bitcoin’s scarce block space should mainly serve monetary transfers, not data storage. -
What is Samson Mow accusing Bitcoin Core of?
He argues that hostility, internal missteps, and bad handling of the OP_RETURN debate helped create the backlash around BIP-110. That is his view, not an independently proven causal chain. -
Why does the policy vs consensus distinction matter?
A default policy affects how software behaves, while a consensus rule affects what the network accepts as valid. BIP-110 is a consensus proposal, so it goes well beyond a simple relay-policy tweak. -
Is this just a technical dispute?
No. It is also a fight over Bitcoin’s purpose: narrow monetary settlement network, or a protocol that can tolerate some broader data use when the economics justify it. -
Was a failed Bitcoin fork identified?
No. The available material says a fork emerged from this kind of policy conflict and later saw extremely low adoption, but it does not name the fork or provide enough detail to pin it down.
Further reading
A few relevant angles on the OP_RETURN and BIP-110 fight worth keeping in your back pocket:
- Bitcoiner Mow Says BIP-110 Uproar Could Have Been Avoided
- 110 Reasons BIP 110 Is a Bad Idea
- Bitcoiner Mow Says BIP-110 Uproar Could Have Been Avoided
- Bitcoin Core v30.0 Released: Fee Cuts, Upgrades, and OP_RETURN Controversy Ignite Debate
- The Great OP_RETURN Liberation: Bitcoin Core Finally Breaks Free from Its Own Artificial Shackles
- Bitcoin Core Removes OP_RETURN Limit: Network Efficiency or Protocol Risk
