BIP-110, Block 961,632 and the Limits of Consensus

At block 961,632, two groups of Bitcoin nodes stopped agreeing about which block was valid. That night, the BIP-110 branch produced two blocks before going quiet. It was the culmination of an argument that had been simmering for months over a deceptively simple question: what, exactly, should people be allowed to stuff onto Bitcoin’s base layer?

The immediate dispute accelerated with Bitcoin Core v30. The release relaxed the default policy around OP_RETURN, a mechanism that allows a transaction to include a small amount of data that is recorded on the blockchain but cannot later be spent as bitcoin. One of the settings involved is called datacarriersize. The name makes it sound more exotic than it is. Think of it as a local filter telling Bitcoin Core how much data attached in this way it is normally willing to pass around the network. Before v30, Core's default policy placed a relatively small limit on these data-carrying outputs. V30 increased the default datacarriersize to 100,000 bytes and allowed multiple data-carrier outputs within the same transaction.

The crucial word there is policy. Core was changing what its software would normally relay to other nodes, not rewriting Bitcoin’s consensus rules. A transaction refused by that filter could still be perfectly valid Bitcoin. If it reached a willing miner by another route and the miner included it in a valid block, ordinary nodes would still accept the block.

That distinction sat at the centre of the argument. Supporters of Core's approach argued that restrictive relay policies were becoming increasingly ineffective. If miners were prepared to include a valid transaction, users could send it directly to them or find other ways of encoding the same information. Refusing to pass it through the normal peer-to-peer network didn’t necessarily keep the data off Bitcoin. It could simply change the route it took.

BIP-110 came from the opposing concern. Its supporters argued that accepting increasingly convenient arbitrary-data channels created costs and incentives that would ultimately be borne by people running Bitcoin nodes. If relay policy could always be bypassed, they wanted the boundary moved somewhere miners could not bypass it: consensus validity itself.

The proposal, formally titled the Reduced Data Temporary Softfork, would impose additional restrictions for roughly one year on output scripts, large witness and script data, several Taproot mechanisms and other channels capable of carrying arbitrary information. Existing UTXOs were grandfathered so coins already created would not suddenly become unspendable under the new restrictions.

BIP-110 therefore raised the stakes considerably. Relay policy allows your node to say, I won't help propagate this transaction. Consensus rules allow it to say, I will not accept a block containing this as valid Bitcoin. Whether Bitcoin should draw that line at all remains the underlying dispute. For a fuller explanation of the arguments around Core v30, arbitrary data and the purpose of Bitcoin’s base layer, read The Fight Over What Bitcoin Is For.

BIP-110’s answer was written into code. The next question was how its supporters intended to get the rest of Bitcoin to follow it.

‍

How the Fork Was Supposed to Work

BIP-110 needed a way to move from a proposal that some people were running to a new set of rules that miners could safely build on. So it started with the usual Bitcoin signalling game. Every Bitcoin block contains a version field, and BIP-110 assigned one small part of that field, version bit 4, as its signal. A miner setting that bit was saying, in effect, “I’m ready for this”. The signals were counted over Bitcoin’s normal 2,016-block difficulty periods, roughly two weeks when blocks arrive at their intended ten-minute pace.

If at least 1,109 of those 2,016 blocks signalled, a threshold of 55%, BIP-110 could move towards activation without a split. But the proposal didn’t require miners to reach that threshold voluntarily. It also contained a deadline. Beginning at block 961,632, nodes enforcing BIP-110 would reject any new block that failed to signal bit 4. A miner could therefore produce a block that ordinary Bitcoin nodes accepted without complaint while BIP-110 nodes treated it as invalid.

This is where some of the language around BIP-110’s activation can become confusing. Block 961,632 was not when BIP-110’s restrictions on arbitrary data were supposed to switch on. It was the beginning of mandatory signalling. If the enforcing chain kept advancing, BIP-110 would reach LOCKED_IN, meaning activation was committed, no later than block 963,648. Another full 2,016-block period would then pass before the reduced-data rules themselves became ACTIVE at block 965,664. Only at that point would blocks violating those new restrictions become invalid under BIP-110.

The final full signalling period before the deadline showed little visible miner coordination around that path. Just 51 of 2,016 blocks carried bit 4, or 2.53%. That number needs to be treated carefully. Signalling is not a democratic vote, and a miner that had not signalled was not necessarily making a philosophical statement against BIP-110. Miners can also change behaviour quickly as an activation deadline approaches. What the number did establish was that, immediately before mandatory enforcement, very little hashpower was publicly producing blocks with the BIP-110 signal.

There was an important precedent in 2017, during the dispute over SegWit, an upgrade that changed how Bitcoin transactions stored certain data and increased the network’s effective capacity. Some users prepared to run BIP-148, a user-activated soft fork that would begin rejecting blocks from miners who refused to signal support for SegWit after a fixed deadline. The crucial difference was the level of preparation around it.

SegWit was already built into Bitcoin Core and supported across the ecosystem, while another proposal, BIP-91, gave miners a way to coordinate before BIP-148’s deadline arrived. By the time users were due to start enforcing the new rule, miners had largely aligned and a lasting split was avoided. BIP-110 entered its own enforcement phase in a very different position, with only 2.53% of blocks signalling in the previous period.

That history matters because a user-activated soft fork can give node operators something very real: the ability to decide which blocks their own nodes will accept. What it cannot guarantee in advance is that miners, businesses, exchanges, wallets and other users will converge on the same decision. The activation mechanism can create the moment when a choice has to be made. It cannot manufacture agreement.

At block 961,632, that moment arrived.

‍

What Happened That Night

Until block 961,631, there was only one history. Nodes running BIP-110 and nodes running the normal Bitcoin rules agreed on every block that had come before it. Block 961,632 was where that agreement ended.

The first block at that height was mined by AntPool, one of Bitcoin’s largest mining pools. It didn’t carry the signal required by BIP-110. For the overwhelming majority of Bitcoin nodes, there was nothing wrong with it and the chain continued normally. Nodes enforcing BIP-110 reached the opposite conclusion. Their new mandatory-signalling rule had begun, so they rejected the block and waited for one that followed the rules they had chosen. This is worth being precise about. The BIP-110 nodes had not malfunctioned, nor had the miners somehow overridden them. Those nodes were doing exactly what their operators had instructed them to do. From their perspective, Bitcoin was still sitting at block 961,631 and waiting for a valid successor.

Eventually one arrived. Roughnecks, a small group of miners supporting BIP-110, found a different block at height 961,632, this time carrying the required signal. They mined it through OCEAN using DATUM, a system that gives individual miners more control over the blocks they attempt to produce. The block contained 4,046 transactions and collected just under 0.039 BTC in transaction fees.

That mining arrangement matters because it would be misleading to describe the event simply as AntPool on one side and OCEAN on the other. A mining pool normally brings many miners together so they can combine their work and receive more predictable payouts. DATUM allows an individual miner to retain much more control over the block it is trying to find while still participating in OCEAN's reward system. The choice to extend the BIP-110 branch was therefore Roughnecks' choice, made using OCEAN infrastructure, rather than a single decision imposed on every OCEAN miner.

Bitcoin now had two different blocks numbered 961,632, both extending the same block 961,631. Ordinary nodes followed the AntPool block. BIP-110 nodes followed the Roughnecks block. This was no longer a hypothetical risk of a chain split. Two groups of nodes were genuinely following different histories.

Roughnecks then found another block on the BIP-110 branch, 961,633. It contained 4,300 transactions and collected a little over 0.060 BTC in fees. For a brief moment, the new branch was moving. Then it stopped cold. No third BIP-110 block followed that night, while the main Bitcoin chain continued adding blocks. The BIP-110 branch would remain at 961,633 for almost 80 hours.

That long pause exposed the harder problem. The rules could determine which blocks BIP-110 nodes accepted, but they couldn’t provide the mining power needed to keep producing them.

‍

Why the Next Block Became So Hard to Find

The branch did eventually move again. On 12 August, almost 80 hours after block 961,633, Roughnecks found block 961,634. Less than four hours later, it found 961,635. The fork was therefore still alive, but the long gap between blocks had exposed the mechanical problem facing it. The BIP-110 branch has only a small fraction of Bitcoin’s mining power behind it, but it has inherited the same mining difficulty as the main chain.

Mining difficulty determines how hard miners must work, on average, to find the next block. Bitcoin normally adjusts that difficulty every 2,016 blocks so that blocks continue arriving roughly every ten minutes even as mining power rises or falls. When BIP-110 split away at block 961,632, however, it inherited the same difficulty as the rest of Bitcoin. There was no automatic reduction simply because very few miners followed it.

That left the branch in an awkward position. It stopped at block 961,635, while its next normal difficulty adjustment would not arrive until block 963,648. In other words, miners would first need to find roughly another 2,000 blocks at the existing Bitcoin-level difficulty before the network could adjust to the much smaller amount of mining power.

The amount of mining power behind the branch has moved sharply since the split. OCEAN’s displayed BIP-110 hashrate reached roughly 36 Exahashes per second (EH/s) on 8 August before falling to around 1.25 EH/s the following day. That initial figure also needs some caution: OCEAN later acknowledged that a configuration problem had inadvertently directed some miners towards the BIP-110 chain. By the time of writing on 12 August, OCEAN’s BIP-110 endpoint was reporting a 24-hour average of around 6.4 EH/s. The main Bitcoin network, by comparison, is operating at roughly 900 EH/s.

Yet the BIP-110 branch is still mining at essentially the same difficulty inherited at the split. At its current 24-hour hashrate, OCEAN estimates an average wait of around 23 hours per block. If that rate somehow remained constant, mining the roughly 2,000 blocks needed to reach the next difficulty adjustment would still take a little over five years. That is not a forecast. Mining is probabilistic and hashpower can move quickly. The point is simpler: the normal difficulty adjustment cannot quickly rescue a branch operating with only a small fraction of Bitcoin’s mining power.

There is also an economic incentive building in the opposite direction. Transactions can continue waiting for confirmation on the BIP-110 branch, including transactions from users who may want to separate coins across the two histories. As more transactions wait, the fees available to whoever eventually mines the next block can increase. But miners still have to weigh those fees against what the same machines could earn mining the dominant Bitcoin chain. A potentially rich BIP-110 block is only interesting if someone is actually willing to point real computing power at it. That is why the almost 80-hour wait after block 961,633 mattered. It showed how quickly a minority chain can slow down when it inherits Bitcoin’s difficulty without anything close to Bitcoin’s mining power.

The BIP-110 nodes still knew exactly which chain they considered valid. What they lacked was enough mining power to keep that chain moving at anything close to Bitcoin’s normal pace. Mining eventually resumed on 12 August, taking the branch to 961,635, but the long pause had already exposed how dependent any minority chain remains on miners actually providing the work needed to extend it.

‍

So What Can We Actually Say Happened?

It would be easy to describe the outcome as BIP-110 simply failing, but that misses what actually happened. The enforcement mechanism worked. Nodes running BIP-110 began rejecting non-signalling blocks at the height they were supposed to. A separate branch was mined, and on the night of the split two blocks followed the rules its users had chosen. None of that was theoretical. What failed was the attempt to attract enough mining power to keep that enforcing branch moving at anything close to Bitcoin’s normal pace.

After reaching block 961,633, the branch stalled for almost 80 hours before Roughnecks mined blocks 961,634 and 961,635 on 12 August. It still remains far from the later stage where activation would become committed, and the reduced-data restrictions that motivated BIP-110 have not come into force. The official BIPs repository now marks the proposal Closed, following the initial chain split and stalled mining.

That distinction matters when describing the event. Saying “BIP-110 activated” suggests the proposed restrictions became part of Bitcoin, which they did not. Saying “Bitcoin rejected BIP-110” turns a complicated coordination process into a vote that never took place. And saying miners simply overruled the nodes ignores the fact that BIP-110 nodes continued enforcing exactly the rules their operators had selected.

The narrow factual conclusion is simpler: BIP-110’s August activation attempt failed to establish an enforcing chain advancing at anything close to Bitcoin’s normal pace. That leaves a more interesting question than who won. What does an episode like this tell us about how Bitcoin changes at all?

‍

What the Fork Revealed

BIP-110 began as a disagreement over arbitrary data, but its activation attempt exposed something more fundamental about Bitcoin. Node operators could choose the rules they were willing to enforce. Miners could choose where to direct their computing power. Developers could write and distribute new software. Businesses, exchanges and holders could decide which chain they continued to recognize and use. Each had influence, but none had enough power to dictate the outcome alone.

That makes consensus frustrating at times, but it is also part of what makes Bitcoin so difficult to capture. Changing the rules of a monetary network should require more than convincing one developer, one mining pool or one sufficiently determined group of users. BIP-110 showed how far one group can go when it chooses to enforce different rules, and how difficult it becomes when the rest of the network doesn’t move with it.

Bitcoiners will keep disagreeing about Core, Knots, blockspace, miners and nodes. Those arguments matter because the rules matter. But they should not make us forget the much larger agreement underneath them. Bitcoin exists as an alternative to a monetary system where the supply can be expanded and the rules rewritten by institutions whose permission we are expected to accept. Bitcoin works precisely because no single participant possesses all the power required to change it.

That principle becomes more meaningful when you apply it beyond the protocol itself. Sovereignty is not only about which rules your node accepts. It is also about how you hold your bitcoin, how you protect access to it, how you recover from mistakes, how much you depend on third parties and whether the people you care about could still access it if something happened to you.

We help people strengthen those parts of their setup, from self-custody and node use to security, recovery, privacy and jurisdictional sovereignty. If you want to understand where your own weak points are and what to improve next, book a free 30-minute introductory call with one of our experts.