BIP-110 Failed: Did Bitcoin Reject Miner Capture—or Prove It Works?

Bitcoin has just produced a governance experiment with consequences that could extend far beyond one failed soft fork.

BIP-110, a proposal aimed at restricting certain non-financial data from the Bitcoin blockchain, reached its Aug. 8 activation deadline with only about 2.5% of network hash power signaling support. Nodes enforcing the proposal subsequently split from the main chain at block 961,632, but the minority chain quickly stalled because it lacked enough mining power.

For supporters of BIP-110, the episode exposed a serious problem: if miners can effectively determine which consensus changes survive, how much power do Bitcoin’s supposedly independent nodes really have?

For critics, the conclusion is almost the opposite.

They argue that BIP-110 failed precisely because Bitcoin’s governance system prevented a proposal without broad consensus from taking over the network.

That disagreement may be more important than BIP-110 itself.

What Actually Happened?

BIP-110 attempted to introduce new restrictions on certain types of data being included in Bitcoin blocks.

But the proposal never achieved meaningful support from miners. Signaling remained around 2.5%, far below its proposed activation threshold.

When the activation deadline arrived, nodes running software enforcing BIP-110 rejected blocks that did not comply with its rules. That created a minority chain separate from the main Bitcoin network.

The problem was simple: the minority chain had almost no mining power behind it.

Because Bitcoin’s proof-of-work system requires miners to produce blocks, the BIP-110 chain quickly became impractical to maintain.

Bitcoin Mechanic, one of the proposal’s prominent supporters, said his node was effectively stuck at block 961,633.

The Deeper Story Is About Who Controls Bitcoin

At first glance, this looks like another failed Bitcoin proposal.

But underneath it sits a much bigger question:

Who actually has the final say over Bitcoin’s rules?

Bitcoin’s design distributes influence across several groups.

Nodes choose which rules to enforce.

Miners provide the computational power required to produce blocks.

Exchanges and custodians influence which chain receives economic support.

Users ultimately determine which version of the network they are willing to use.

The BIP-110 dispute has exposed the tension between these groups.

Its supporters argue that miners have accumulated too much influence because a proposal supported by some node operators could not survive without mining support.

Critics argue that this is exactly how Bitcoin is supposed to work: no controversial change should be able to force itself onto the network without broad coordination.

The Miner-Capture Argument

Bitcoin Mechanic sees the result as evidence that Bitcoin’s original governance philosophy is weakening.

He argued that the episode shattered his belief that decentralized full nodes could act as a meaningful check against miner power.

His criticism goes to the heart of Bitcoin’s philosophy.

If miners control the practical ability to keep a chain producing blocks, then a group controlling significant hash power can potentially determine which competing chain remains economically viable.

For Bitcoin Mechanic, that raises the possibility of what he describes as “protocol capture.”

He has even argued that proof-of-work becomes less meaningful if the people performing the work effectively determine which rules are treated as valid.

That is a serious criticism—but it is not the only interpretation.

The Counterargument: Bitcoin Worked Exactly as Designed

Leo Fan, founder and CEO of Cysic, offers a very different explanation.

Rather than seeing the failure as proof of miner capture, Fan argues that Bitcoin’s difficulty-adjustment system is doing what it was designed to do.

A minority chain that inherits Bitcoin’s existing mining difficulty but attracts only a tiny fraction of the network’s hash power will struggle to produce blocks.

In simple terms, imagine two roads requiring the same amount of work to clear, but one road has 97% of the workers while the other has only 3%.

The second road isn’t necessarily being “attacked.”

It simply doesn’t have enough workers to keep up.

Fan’s broader argument is that Bitcoin’s authority is not concentrated in one group.

“Nodes choose which rules to enforce, miners determine whether a chain keeps producing blocks, and exchanges and users determine which chain retains liquidity and the Bitcoin identity.”

That presents a very different picture of what happened.

Was the Real Problem BIP-110’s Design?

This may be the most important criticism of the proposal.

With miner support hovering around 2.5%, forcing activation created a predictable problem.

Once the minority chain separated, it inherited Bitcoin’s difficulty but lacked Bitcoin’s hash power.

That meant block production could become extremely slow.

Fan therefore argues that the proposal’s activation mechanism was itself flawed.

His principle is simple:

“Activation thresholds should confirm consensus, not manufacture it.”

In other words, if a proposal has only single-digit support, the appropriate response may be to withdraw it, redesign it or build more consensus—not force the network into a split.

This argument shifts the debate away from “Did miners capture Bitcoin?”

and toward:

“Did BIP-110 attempt to activate a contentious change before enough of the ecosystem was ready?”

Why the Minority Chain Stalled

The technical lesson here is important for investors who follow Bitcoin forks.

Bitcoin’s proof-of-work system adjusts mining difficulty based on the network’s history.

When a small group leaves the main chain, the new chain does not automatically receive a proportionally easier version of Bitcoin’s mining requirements.

So if a minority chain has only around 2.5% of the original hash power but inherits the same mining difficulty, blocks can take dramatically longer to produce.

That is effectively what happened with BIP-110.

The result was a chain that technically existed but could not operate efficiently.

And that distinction matters:

Creating a blockchain is relatively easy. Creating a blockchain with enough economic and computational support to become viable is much harder.