At block height 961,632, a small group of Bitcoin nodes running software that enforces a proposal called BIP-110 rejected a block that didn't signal support for the change — and split off from Bitcoin's main network as a result. It's the kind of event that sounds dramatic in headlines but, so far, looks more like a case study in how Bitcoin's governance-by-consensus model plays out in practice than an existential threat to the network.
What BIP-110 actually proposed
BIP-110, formally titled "Reduced Data Temporary Softfork," is a proposal authored by developer Dathon Ohm with input from longtime Bitcoin contributor Luke Dashjr. It's designed as a one-year rule limiting the size of arbitrary, non-financial data fields in Bitcoin transactions — aimed squarely at data-storage techniques like Ordinals inscriptions and Runes, which use Bitcoin's block space to store images, text, and other content unrelated to payments. The proposal reflects a long-running debate in the Bitcoin community over whether block space should be reserved primarily for financial transactions or left open to any use the network can technically support.
As a User-Activated Soft Fork (UASF), BIP-110 required 55% of mining power to signal support in order to activate without splitting the network. That threshold was never close to being met — miner signaling fluctuated between roughly 0.3% and 2.6% in the weeks leading up to activation, and no major mining pool publicly backed the proposal.
How the split unfolded
Despite that lack of support, BIP-110's mandatory signaling window began as scheduled. When the first block after height 961,632 arrived without the required signal — mined by leading pool AntPool on the main chain — nodes enforcing BIP-110 rejected it and followed an alternative, compliant block instead, produced through Ocean Mining by a pool called Roughnecks. That moment marked the actual chain split: two versions of Bitcoin's transaction history, diverging block by block from that point forward.
The divergence widened quickly. By roughly 6 p.m. ET on the day of the split, Bitcoin's main chain had reached block 961,640 while the BIP-110 chain sat far behind. By early the next morning (around 1 a.m. UTC), trackers placed the main chain at block 961,654 versus 961,633 on the enforcing branch — a 21-block gap. Community-run monitoring tools, including a dedicated BIP-110 situation tracker, allowed anyone to watch the divergence unfold in close to real time, alongside a live leaderboard of which mining pools were signaling for which chain.
Why support never materialized
The core problem for BIP-110 was structural: without meaningful mining power, a forked chain simply can't produce blocks at Bitcoin's normal roughly-10-minute pace. The breakaway chain inherited Bitcoin's existing mining-difficulty setting, but with only a sliver of the network's total hash power behind it, blocks arrive far more slowly. Difficulty can't adjust downward until the chain completes a full 2,016-block cycle at its current pace — which trackers estimated would take around 350 days, versus roughly 14 days for Bitcoin's main chain under normal conditions. In practice, that made the fork's long-term viability extremely unlikely from the moment it launched.
That prediction played out quickly: the minority chain managed to produce just two blocks in the roughly eight hours after the split, with no clear sign that any significant miner intended to keep extending it.
The practical risks for holders
For most Bitcoin holders, this event is more of an operational curiosity than a financial threat — but it isn't entirely risk-free for everyone. Both chains, at least in this early stage, accept identical transaction formats, meaning a transaction signed to spend "fork coins" on the minority chain can also be valid on Bitcoin's main chain. That opens a theoretical replay-style risk: someone could receive a payment intended only for the fork chain, then rebroadcast the same signed transaction on the main Bitcoin network and collect real BTC from the same sender. Developers have specifically cautioned users against assuming any transaction is cleanly isolated to one chain during this period.
For anyone running a full node with BIP-110 enforcement enabled, the split also has an immediate practical consequence: that node is now out of sync with the Bitcoin network most people, exchanges, and services actually use. Node operators in that position generally need to either disable BIP-110 enforcement and resync with the main chain, or continue operating in relative isolation on the minority network.
What this episode illustrates about Bitcoin
Bitcoin doesn't have a central authority that approves protocol changes by decree — it changes through rough consensus among developers, miners, node operators, and exchanges, expressed through the software they choose to run. BIP-110 is a clear, real-time illustration of what happens when that consensus doesn't form: rather than the change being imposed on the network, the network effectively rejected it by simply not adopting the enforcing software in meaningful numbers, leaving its supporters isolated on a chain with little practical ability to sustain itself.
That's a structurally different outcome from Bitcoin's most consequential historical upgrades, like SegWit, which did secure broad miner and ecosystem support before activating network-wide without triggering a lasting, viable competing chain. Whether or not BIP-110's fork chain persists in any form, the episode is a useful, concrete example of how Bitcoin's "governance by running code" actually functions under real pressure — for readers who want the underlying mechanics, our guide on how blockchain technology works covers the basics of how distributed consensus operates.
