BIP-110 Explained: What a Contested Soft Fork Reveals About Bitcoin Consensus

The question underneath the fork

BIP-110 is easy to file under the long-running argument about Ordinals and arbitrary data on Bitcoin. That framing misses what is actually at stake. The proposal does not add a local filter that each node operator can choose. It changes the consensus rules that decide which blocks belong to Bitcoin at all.

That is a different kind of change. A spam filter is a preference. A consensus rule is a definition. BIP-110 asks a question that sits above the data debate: should Bitcoin only check whether a transaction is valid under neutral rules, or should the rules also forbid certain uses of blockspace? And a second question follows from the first: how far may a minority go to impose its preferred answer?

This is an analysis of those questions and of the mechanics that make them urgent this month. CanoeBit takes no view on Bitcoin's price and makes no recommendation about what anyone should do. For the current state of play, the activation timeline, and the reported client bug, see the news report BIP-110 nears mandatory signaling.

What BIP-110 actually restricts

For about one year, or 52,416 blocks, BIP-110 would add seven consensus rules. New output scripts would be capped at 34 bytes, with OP_RETURN outputs allowed up to 83. Data pushes and script argument witness items would be limited to 256 bytes. Undefined witness and Tapleaf versions could not be spent, the Taproot annex would be forbidden, control blocks would be capped at 257 bytes, and OP_SUCCESS as well as executed OP_IF and OP_NOTIF instructions would be invalid in Tapscript.

The important nuance is that these rules are general. They target the techniques inscriptions rely on today, but they reach into Script, witness data, and several Taproot upgrade paths broadly. The specification itself concedes narrow, experimental cases involving pre-signed Taproot transactions where funds could in theory be frozen or lost, even as it takes real care to grandfather every coin confirmed before activation.

So the proposal is not a clean "Ordinals ban". It is a broad tightening of what a valid Bitcoin transaction may look like, with a small residual risk to legitimate but undocumented uses. That is a meaningful thing to weigh, not because the risk is large, but because nobody can enumerate every contract construction already in the wild.

The steelman: why the concern is legitimate

The frustration behind BIP-110 is not unreasonable, and it is worth stating at full strength before taking it apart.

Full nodes must download and validate every block. Unspent output scripts live in the UTXO set, which nodes keep on fast storage and cannot prune. Large inscriptions compete with monetary transactions for scarce blockspace, they can raise fees for ordinary payments, and some of the embedded content is material that node operators would rather not host at all. If you believe Bitcoin's first purpose is to be money, watching its blockspace fill with data that free-rides on every node forever is a genuine grievance.

That case is coherent. The disagreement is not about whether data embedding has costs. It is about whether a temporary, low-threshold consensus change is the right instrument for addressing them.

Where the reasoning gets thin

Two problems weaken the proposal on its own terms.

The first is economic. Satoshi's original design already contains an anti-spam mechanism: fees and a hard block size limit. When blockspace fills, it gets expensive, and uses that carry no monetary return tend to price themselves out. This is not theory. Inscription waves have repeatedly cooled as fees rose and the activity stopped paying for itself. A consensus rule that merely makes one method harder invites the data to move rather than disappear.

The second problem is worse, and it is where the cure may feed the disease. If contiguous data storage in obvious fields is banned, determined actors can split payloads across many small pushes or disguise them as ordinary financial data. Spread across many outputs, that data can end up in the UTXO set, the one part of the chain nodes cannot prune. In the effort to keep unwanted data out, the change risks relocating it into the most expensive place to store it. The proposal does not deny this. It argues that fragmentation and higher cost still send a message. That is a real point, but it is a message, not a fix.

How a chain split would form

The mechanics of the split are simple, which is part of why the risk is credible. From block 961,632, BIP-110 nodes and ordinary Bitcoin nodes apply different rules. If a block sets bit 4, both sides can accept it. If a block does not, ordinary nodes still treat it as valid, and BIP-110 nodes reject it.

At that moment the two groups stop following the same chain. With the overwhelming majority of hashrate not signaling, the ordinary Bitcoin chain would continue almost undisturbed, while BIP-110 nodes would wait for one of the few signaling miners to produce a block on their branch. A second chain can exist technically. Whether it matters economically is a separate question, and the current data does not suggest it would.

Two design choices sharpen the danger. There is no general replay protection, so a transaction can be valid on both chains at once, a hazard past forks have demonstrated when users move coins in the first hours. And the activation client itself carries the reproducible upgrade bug documented in the BlockSlop report, in which two nodes running the same enforcing rules can end up on different chains depending on their data directory history. A consensus change whose own client cannot guarantee that identical nodes agree is not a mature one.

The number that decides everything

The signaling threshold is the quiet center of this dispute. Taproot, an uncontroversial and purely additive upgrade, was deployed with a 90 percent miner threshold. BIP-110, which removes existing capabilities and can trigger a split, sets its bar at 55 percent.

That inversion is telling. The higher-risk change asks for less agreement than the low-risk one did. The proposal's defense is that a temporary, one-year rule does not need near-universal readiness. Read structurally, though, the low threshold looks less like a safety margin and more like an attempt to clear a bar that broad support cannot reach on its own. And even 55 percent is not close: signaling has sat in the low single digits for the entire deployment.

Here the term "mandatory signaling" invites a misreading. It does not force miners to activate anything. It only means BIP-110 nodes will reject non-signaling blocks from that height. If most miners keep producing ordinary blocks, those blocks remain valid for the rest of the network, and the BIP-110 nodes are the ones left behind. A user-activated soft fork can pressure miners, but only when a credible economic majority of exchanges, custodians, wallets, and users refuses everything except the stricter chain. No such majority is visible for BIP-110.

A chain that would crawl

Suppose a separate BIP-110 chain does form and holds the small hashrate now signaling, roughly one and a half percent of the network. It would inherit Bitcoin's current difficulty with a fraction of the power to meet it.

The arithmetic is unforgiving. Blocks would arrive on average about every eleven hours instead of every ten minutes, close to 68 times slower. Bitcoin only retargets difficulty every 2,016 blocks, and at that pace reaching the first adjustment would take on the order of 950 days, about two and a half years. Until then the chain would produce occasional blocks, not a functioning payment network. A minority chain is technically possible. A usable one, on these numbers, is not.

CanoeBit's reading, and where it breaks

Our structural read is this: BIP-110 is far more likely to produce a small, slow, largely ignored minority chain than to change Bitcoin, and its activation design substitutes assertion for consensus. Repeating that a proposal has consensus does not create it. Consensus appears when independent users, miners, developers, and businesses converge on rules voluntarily, and that convergence is not visible here.

Because an honest analysis names its own failure conditions, here are ours. This reading would break if a meaningful share of hashrate migrated to the BIP-110 branch, or if major exchanges, custodians, and wallet providers committed to treating only the stricter chain as Bitcoin. In that case a real economic majority would exist and the calculus would change. It would also break if the low signaling figures were badly mismeasured and true readiness were far higher than the dashboards show. Neither condition is evident today, but both are observable, and both are what we would watch to know we were wrong.

The narrower point stands regardless of how the fork resolves. A debate about blockspace and data storage is worth having. Deciding it through a hastily built, low-threshold consensus change, enforced by a client with a known divergence bug, is a poor way to have it.