Issue #24: BIP-110 Is a Statement
BIP-110 is being read as a patch awaiting activation. That reading is too small.
BIP-110 is a statement, compiled into running code.
The BIP itself frames it technically: ‘temporarily limit the size of data fields at the consensus level, to correct distorted incentives caused by standardizing support for arbitrary data, and to refocus priorities on improving Bitcoin as money.’
The position underneath that language is sharper: Storing arbitrary large files in every Bitcoin node, forever, is a use case we reject.
Not “discourage.” Not “tolerate with margin.” Reject.
That position is now manifested in production, on the network, in real blocks.
The downside scenarios of storing large payload into the blockchain don’t require much imagination: Illegal content, doxxing payloads, state-leveraged material placed deliberately to compromise node operators, copyright-laundered files designed to invite legal action against anyone running the software.
The cost of allowing this use case to prosper is asymmetric and irreversible. The cost of rejecting the use case is bounded. Some marginal use cases get pushed off-chain, where most of them belonged anyway.
That tradeoff is the position BIP-110 encodes.
Who decides?
Filtering is what every Bitcoin node does, every day, with every transaction.
So the question is not whether the protocol filters but which use cases it’s optimized for.
“Who decides?” is a fair question and the answer BIP-110 gives is the only one that’s ever held up in a system without formal authority: Those who see the threat clearly enough to act, take the exposure of leading, and put real hashpower behind the position.
Why the artifact is permanent
A statement on X is a tweet. A statement in a forum post is a forum post.
A statement compiled into a soft-fork proposal, deployed by thousands of independent pool operators, signaled in real blocks, and visible in mempool acceptance behavior is something else: it’s a part of Bitcoin operationalizing its conviction. The artifact stays in the historical record.
The practical consequence matters because the bad scenario isn’t accidental. A genuinely damaging file landing on chain would not be a fluke. It would more likely be deliberate, placed by actors who want Bitcoin to fail, calibrated to maximize legal, political, or reputational damage. That’s the shape of the threat.
BIP-110 is what the first deployed line of defense looks like. It doesn't stop every vector as sophisticated attackers could still construct payloads that comply with its rules, but it considerably narrows the attack surface. It also forces remaining placements into clearly engineered workarounds rather than uses of the protocol's standard paths. The next iterations (dynamic filters, additional policy refinements) can then build on a deployed foundation rather than starting from a blank page.
What has already shifted
A few things already changed because BIP-110 exists, including:
The governance debate is now measurable. Where actors stand is now legible. Barefoot Mining and 234 Alberta committed. ~9% of nodes running BIP-110. The hashrate share is still small but the difference between zero and not-zero is categorical.
A precedent now exists that constrains Bitcoin's future. A non-zero portion of hashrate has signaled support for a soft-fork that Bitcoin Core has not yet adopted into its release software. That's structurally different from previous miner-signaled soft-forks (SegWit, Taproot), which Core implemented and shipped. The fact reshapes the game theory of future protocol decisions. Whatever anyone proposes from here, they propose into a different governance topology than the one that existed 12 months ago.
Closing
The activation question is real.
The deeper question was whether the “Bitcoin is money, not a publishing layer” position would remain vibes and frustration, or become something concrete enough to defend the chain.
BIP-110 settled that. The line has been drawn, in code, in blocks, on the network.
Until next week.
— Renaud
If you found this analysis is useful, consider subscribing. It helps this work continue.
Disclaimer: This newsletter provides data analysis and commentary on Bitcoin network activity. It is not financial nor legal advice. I have no financial stake in Bitcoin Core vs Knots, mining pools, or any related projects. Data accuracy: blockchain analytics involves classification decisions that may differ from other methodologies. I welcome corrections from any party who believes data presented here is inaccurate.