Limiting arbitrary data is a slippery slope toward protocol-level censorship. Bitcoin's strength lies in its refusal to discriminate between users or use-cases.
Live estimate to the BIP-110 fork block, following the same countdown logic used by jlopp.github.io/knotzi-death-march.
Bitcoin is designed to be a "dumb pipe." By defining certain data as "spam," BIP-110 introduces subjective human morality into the base layer. If we can filter images today, what will be filtered tomorrow?
Ref: Adam Back (Blockstream) → Full argument page →As the block subsidy approaches zero, Bitcoin must rely on fee revenue. Inscriptions have paid over $500M to miners. BIP-110 removes this income, making the network more vulnerable to 51% attacks.
Ref: Miner Security Reports → Full argument page →Filters don't stop data; they drive it underground. BIP-110 incentivizes "out-of-band" payments, where users pay miners privately to include data, creating a centralized, opaque market for blockspace.
Full argument page →"It's a lynch mob attempt to push changes there is not consensus for... BIP-110 would be an attack on Bitcoin's credibility as a neutral store of value."
The proposal's technical constraints carry risks beyond just "spam" removal.
The limits on script tree depth intended to stop inscriptions are the same tools used for BitVM and advanced smart contracts. BIP-110 may inadvertently "brick" the future of Bitcoin scaling.
Ref: Jameson Lopp Critique → Full fallout page →Retroactively changing what is "standard" can make pre-signed transactions or timelocked wallets unspendable. This is viewed by critics as a forced confiscation of user property.
Ref: The Bitcoin Manual Analysis → Full fallout page →Based on Jason Hughes' July 15, 2026 notes to miners, these objections focus on what BIP-110 changes for block producers, fee discovery, coordination, and the long-term political attack surface around Bitcoin policy.
BIP-110 tries to block one style of payload insertion, but arbitrary data can migrate into other script constructions and transaction patterns. That means miners take on coordination risk without actually removing the underlying demand.
Ref: Jason Hughes, notes to miners →If public relay and wallet tooling reject some transactions, large users can still bypass that path and negotiate directly with miners or pools. The result is less transparent fee discovery and more advantage for insiders with direct relationships.
Ref: Jason Hughes, notes to miners →Once a soft fork is used to ban a disliked use of blockspace, future arguments stop being narrowly technical. Miners become the pressure point for every new campaign about what Bitcoin should or should not allow.
Ref: Jason Hughes, notes to miners →A contentious rollout forces miners and pools to guess which chain wins, how exchanges react, and whether reorg risk will spike. BIP-110 is not just a policy statement; it is an operational risk event for the entities securing the chain.
Ref: Jason Hughes, notes to miners →Fee-paying demand is still demand, even when some users dislike the application consuming blockspace. Overriding that market signal with social preferences weakens the credibility of Bitcoin's neutral auction for inclusion.
Ref: Jason Hughes, notes to miners →The more Bitcoin relies on custom filtering, private order flow, and contentious-chain coordination, the more the advantage shifts toward large pools with deeper relationships and better legal or communications posture. Smaller operators get less say while carrying the same consensus risk.
Ref: Jason Hughes, notes to miners →A few of the clearest public critiques published across blogs, news coverage, and online commentary.
In his February 23, 2026 essay, Jameson Lopp argues that BIP-110 raises chain-split risk, can freeze edge-case funds, constrains future upgrades, and still fails to stop arbitrary data because users can route around the rules.
Read: A Layman's Guide to BIP-110 →Coverage of Adam Back's X comments frames BIP-110 as more dangerous than the problem it tries to solve: he warns it would damage Bitcoin's credibility and could freeze some UTXOs through consensus-level restrictions.
Read: Adam Back Opposition Coverage →The Bitcoin Manual explains that a UASF can pressure miners, but it also stresses the main downside: if economic support is overestimated, BIP-110 can trigger a minority chain, split liquidity, and create coordination failures across the ecosystem.
Read: What Is BIP-110? →If BIP-110 causes a contentious chain split without replay protection, the same transaction can be valid on both chains. That opens the door to accidental replays, deposit confusion, fake wallet-support scams, and double-spend style fraud against users and exchanges.
Read: Lopp on chain-split and replay risks →Lopp cites Andreas Antonopoulos to argue that ideological purity spirals end in self-parody. In this framing, BIP-110 is less a technical fix and more a political attempt to cancel uses of Bitcoin that some factions dislike.
Read: Lopp quoting Andreas on purity politics →Lopp also points to Murch's public thread rebutting the claim that BIP-110 can safely win after activating with minority hashrate. That criticism cuts directly against the idea that a contentious rollout would resolve cleanly.
Read: Lopp linking Murch's rebuttal →In his September 23, 2025 article, Lopp argues that Knots inherits a basic trust problem because binaries were still being served from infrastructure he describes as known-compromised. His point is straightforward: if release hygiene is weak, users are being asked to trust a riskier software pipeline.
Read: It's Knot a Serious Project →Lopp also criticizes Knots as an opaque single-maintainer fork: merge history is harder to audit, merge commits are not signed the way Bitcoin Core's usually are, and upstream review does not cleanly carry over. That matters because contentious consensus changes should face more scrutiny, not less.
Read: Lopp on Knots' software lifecycle →Another thread in Lopp's article is that Knots governance is not just technically contentious but politically loaded: he ties the project to hostility toward mixing, privacy tools, and even collateral damage for systems like Whirlpool and Lightning. That adds a broader ecosystem risk beyond the narrow BIP-110 rule change itself.
Read: Lopp on privacy and ecosystem fallout →In his July 15, 2026 X post, Michael Saylor calls BIP-110 a “Bitcoin Iatrogenic Proposal”: a treatment that causes harm. The objection is that changing Bitcoin’s consensus rules to address unwanted data could be more damaging than the issue it seeks to address.
Read: Michael Saylor on X →Saylor argues that there are greater threats to Bitcoin than spam, and that turning this dispute into a consensus change is the real risk. His concern is that BIP-110 would invalidate currently valid, fee-paying transactions and establish a harmful precedent.
Read: Michael Saylor on X →Saylor’s related message assigns distinct roles to fees, nodes, miners, and holders. Protocol changes, he says, must earn overwhelming alignment so bad ideas fail before they can damage Bitcoin.
Read: Michael Saylor on X →DathonPwn reports a potential late-upgrade consensus bug in BIP-110. Under the reported scenario, nodes upgraded from older software retain their existing chain history while fresh BIP-110 nodes reject that same history, creating the risk of a hidden chain split.
Read: DathonPwn on X →The reported flaw is serious because the same historical chain must be evaluated consistently. If an in-place upgrade accepts history that a new installation rejects, operators can unknowingly run nodes that disagree about which chain is valid.
Read: DathonPwn on X →The claim highlights a basic deployment requirement for consensus software: a node that upgrades in place and one that syncs from scratch must arrive at the same consensus state. If that property fails, BIP-110 adds operational uncertainty precisely when the network needs reliable coordination.
Read: DathonPwn on X →