A chain split is, at first, indistinguishable from a typo. On the day the BIP-110 fork was supposed to announce itself to the network, the only evidence was a pair of blocks carrying a version field no other miner on the Bitcoin network recognized. Two blocks, mined in quick succession, each containing the quiet cryptographic signature of a client that believed it could force a proposal onto a ledger that had decided โ without a vote, without a tweet, without a whitepaper โ not to listen. Then the coinbase timestamps stopped advancing. The chain went cold. What followed was not a civil war, not a treasury drain, not even a particularly heated forum thread. Just two orphans, fatherless in the eyes of the longest chain, resting at a height that no future block would ever extend.
I have spent most of the last decade studying failures like this one. Back in 2017, I spent three months of my evenings auditing the smart contract infrastructure of emerging ICOs, most of which nobody remembers today. That experience taught me that a smart contract fails in one of two ways: loudly, by draining millions in a reentrancy exploit, or quietly, by never being used. The BIP-110 fork belongs to the second category. It is the kind of failure that gets filed under testnet noise and forgotten. But tracing the static in the protocol's genesis block โ the buried assumptions, the miscalculated social dynamics, the engineering hubris โ reveals more about how Bitcoin actually changes than any approved proposal ever will.
The public debate around this fork was framed as a debate over code. It was never about code. It was about an unwritten rule that a protocol changes only when the people who run it change together. And the fork attempt violated that rule in the most instructive way possible: it mined two blocks, then the world moved on.
The Context: A Proposal Nobody Asked to Be Forced
To understand what the BIP-110 fork tried to do, one has to rewind to the most unflattering period of Bitcoin's adolescence: the block size war. Between 2015 and 2017, the network found itself caught between two incompatible futures. On one side sat a community that believed Bitcoin's value proposition was scarce digital property, best protected by a conservative, immutable base layer. On the other sat a coalition that believed Bitcoin had to scale its transaction throughput or be rendered irrelevant by newer, faster chains. The argument produced an entire taxonomy of failed heirs: Bitcoin XT, Bitcoin Classic, Bitcoin Unlimited, and finally Bitcoin Cash โ each one a fork carrying a slightly different version of the same promise that the base layer could be updated if enough people simply insisted.
BIP-110 sits inside that lineage, though it is rarely remembered alongside the household names of the fork wars. Formally, it proposed changing the default signature hash digest algorithm โ a piece of the transaction validity rule that determines exactly which parts of a transaction a signature commits to. To a casual observer, that sounds like plumbing. But the proposal was quietly essential to the larger ambition of increasing block sizes: the existing signature hashing scheme required transaction data to be hashed repeatedly in a way that scaled poorly, and a new digest algorithm would make validating larger blocks dramatically cheaper. In other words, BIP-110 was a prerequisite. A key that would unlock a door that many miners and node operators had explicitly said they did not want to open.
The ordinary way to make such a change is through the network's own governance machinery: version bits, miner signaling, threshold activation windows, then a patient waiting period during which the economy recompiles itself around the new rules. This process is slow, deliberate, and deliberately boring. Its slowness is not a design flaw; it is the entire point. A change that takes eighteen months to activate gives every exchange, every custodial wallet, every hardware manufacturer time to adjust. The BIP-110 fork attempted to skip all of that. Instead of waiting for activation thresholds, the fork client simply changed the consensus rules unilaterally, starting a new chain that shared Bitcoin's entire history but diverged at a block height of the fork team's choosing. It was, in the purest sense, an act of legislative capture executed with code instead of a gavel.
The Core: Anatomy of a Forced Blessing
Let me be precise about what happened, because precision matters more than drama. The fork client enforced BIP-110's new signature digest at a predetermined activation height. For the first two blocks after that boundary, the client's own miners found valid blocks under the new rules. Those blocks were, by every internal measure, well-formed. Their headers were sound. Their transactions were valid under the fork's rule set. Their difficulty was inherited from the same chain they had left. And yet the moment those blocks were broadcast, the rest of the network treated them as invalid โ not because they were malformed, but because they violated the rules that the dominant client continued to enforce. The canonical chain simply ignored them. Within minutes, the fork's two blocks were orphaned by height, stranded at a point in history where the longest chain had already moved on.
There is a temptation to call this a technical failure. It was not. Every piece of software involved performed exactly as written. The fork's miners did their work. The canonical miners did theirs. The failure was not in the code but in the relationship between the code and the economic reality it tried to override. This is the first insight that the two-block episode offers: a fork that does not carry the consent of the network's economic majority is not a chain at all. It is a local cache. It is a private ledger with a public timestamp. The hashpower behind it, however honest, becomes indistinguishable from an attack.
To understand why, consider the economics of orphandom. A miner on the canonical chain receives a block subsidy plus fees, paid out because the network collectively agrees that the miner's work extends the one true history. A miner on the fork receives the same nominal subsidy, but the coins exist only inside a ledger that no exchange will list, no wallet will display, and no merchant will accept. The fork's Bitcoin is not Bitcoin; it is a claim on a belief that has not yet formed. The fork team likely assumed that once a few blocks were mined, the network would see the code was sound and follow. But the network does not follow code. The network follows a tacit social compact that is renewed with every block. In the moment those two orphaned blocks were broadcast, the compact was renewed without them.
This is where the concept of the security budget becomes useful. A chain's security is not the amount of hashpower pointed at it on a given afternoon. It is the expected value of that hashpower over a long horizon, discounted by the probability that the chain survives. The canonical Bitcoin chain has a security budget that compounds because fourteen years of continuous operation have created a market of holders, lenders, and businesses whose livelihoods depend on its immutability. The two-block fork had a security budget of precisely two blocks. It had no exchange listings, no treasury, no developer ecosystem, no derivative markets, no custodians, no insurance products, no mempool of waiting users. It had nothing but a rule set and a hope. Security is a silent promise kept between nodes, and the fork had made a promise to a constituency that did not exist.
There is a second, subtler technical lesson hiding in the fork's short life, and it concerns the difficulty adjustment. Bitcoin's difficulty retargets every 2016 blocks to keep block production at roughly ten minutes. A fork that starts from Bitcoin's history inherits the current difficulty. That means the fork team needed to solve the same cryptographic work per block as the canonical network, despite controlling a tiny fraction of the hashpower. The two blocks they mined were therefore enormously expensive, both in electricity and in opportunity cost. Every second they spent mining an orphaned chain was a second they were not earning canonical Bitcoin. This is the hidden tax on any unilateral fork: the inherited difficulty makes the first weeks of the new chain brutally expensive, and the retarget mechanism rewards patience, not force. The fork died before its first retarget, but even a successful retarget would have left it with a chain that was exquisitely slow and crushingly expensive to secure. Most forks that manage to survive, like Bitcoin Cash, survive only because they command exchange support and a vocal narrative. The BIP-110 attempt had neither.
The Story the Logs Tried to Hide
The most revealing artifact of the entire episode is the version field in those two blocks. In Bitcoin's activation history, the version field is where governance is written. Miners signal readiness for proposed upgrades by setting bits in their block headers, and once enough blocks carry the signal, the upgrade activates. The BIP-110 fork's blocks carried a version that signaled its own broken promise โ an assertion that the network had consented when it so clearly had not. If I have learned anything from reading protocol logs the way a pathologist reads tissue samples, it is that every bug is a story the system tried to hide. The version field was not a bug. It was a boast. And the network answered the boast with a silent shrug.
I cannot help but compare this to the upgrade attempts I have watched inside DeFi. Nearly every governance crisis of the last four years follows the same arc: a team with a treasury, a white paper, and a sense of urgency tries to force a change through โ a new oracle feed, a migration, a token conversion โ and is shocked when the community treats the forced change as a hostile act. In 2020, during my research on MakerDAO's collateralized debt positions, I watched how the community debated risk parameters not as technical inputs but as expressions of trust. The same oracle feed that was mathematically sound could be socially rejected if it felt imposed. The lesson was the same then as it is now: a protocol's rule set is a constitution, and constitutions cannot be amended by unilateral declaration.
This is also why the current bull market makes me uneasy. Euphoria does not discriminate between proposals that build and proposals that merely demand. Every cycle, fresh money arrives looking for the next upgrade, the next fork, the next narrative of liberation from the old chain. Some of those projects are dressed in the same clothes as the BIP-110 fork: a fresh client, a reasonable-sounding improvement, a belief that the weight of the argument alone will move the network. My audit instinct, developed over years of reading smart contracts line by line, tells me to look not at the argument but at the incentives. Does the proposal carry its own economic constituency? Does it offer exchanges and custodians a reason to recompile their entire stack? Does it create value for the people who will have to do the dangerous work of migrating? If the answer to those questions is no, the proposal is not a fork. It is a two-block wish.
The Contrarian Reading: Failure Was the Feature
Now I want to argue for something uncomfortable: the BIP-110 fork was not a mistake. It was a functioning part of Bitcoin's immune system. The network's conservative posture is often criticized as a barrier to innovation, and for years I shared that frustration. But a failed fork performs a crucial public service. It tests the boundary of consensus at almost no cost to the network itself. The two blocks were a probe, and the network's response โ indifference โ was the measurement. This is how immutability is actually maintained: not by writing good code, but by continuously demonstrating that bad attempts to change the code will be absorbed and ignored.
The contrarian insight here is that the cheapness of the attempt is what makes the system strong. Consider what a successful forced activation would have required. It would have required a coordinated switch by exchanges, wallet providers, and thousands of nodes. That coordination could never have happened overnight, which is precisely why the attempt was never going to succeed no matter how sound its code was. The cost of the attempt, in hashpower and developer time, was a few thousand dollars. The cost to Bitcoin of repelling it was zero. Stability is the quiet architecture of trust, and trust, in this case, was maintained so effortlessly that most people never noticed the network had been under a soft coup attempt at all.
There is a blind spot in the way the industry discusses these episodes, and I want to name it plainly. The typical commentary after a failed fork says that the market rejected the code. That is a comforting but wrong explanation. The market never evaluated the code. Almost nobody read the patchset. The rejection happened at the level of identity: the fork had no name recognition, no cultural resonance, no story. The image is not the asset; the belief is. The fork owned an image of innovation but no belief to attach it to. If the same BIP-110 patch had been bundled into a cultural movement with a charismatic name, an exchange listing, and a crusade against the establishment, the outcome would have been entirely different. In a bull market, where attention is the scarcest asset, this distinction matters more than the technical merits of any proposal.
The deeper blind spot is that we keep expecting the next Bitcoin-level fork to look like the last one. We scan version bits and watch for hashpower migrations. But the next challenge to Bitcoin's consensus is not arriving in the form of a chain split. It is arriving in the form of sidechains that promise expansion without forking, of layer-two networks that concentrate settlement risk in a single sequencer, of wrapped assets that depend on a custodian's word instead of the base layer's proof. I have written for two years now that layer-two sequencers are effectively single centralized nodes, that decentralized sequencing has lived on PowerPoint slides longer than most venture funds hold their positions. The BIP-110 fork failed because it asked the entire network to change at once. The next attempt will not ask. It will quietly absorb liquidity elsewhere, then claim the base layer is obsolete.
What the Two Blocks Leave Behind
Yields do not vanish; they merely change form. The same is true of failed forks. The value of the energy spent on those two blocks did not disappear into a void; it was transformed into a signal that future fork teams can read โ if they choose to. The signal is this: the network's consensus is not a technical property but a social one, and no patch can override it. Every upgrade that actually ships, from SegWit to Taproot, ships because it solved the social problem first and the technical problem second. The order is not negotiable.
As a fund manager, I spend my days reading the static in these narratives. I ask not whether a project's code is elegant, but whether its community has the patience and the mutual trust required to activate change. The BIP-110 fork is a tombstone in the graveyard of forced upgrades, and I would rather read tombstones than write them. The next time a freshly funded project announces that it will harden Bitcoin, or modernize it, or free it from the tyranny of its own caution, I will ask one question before I look at a single line of code: who is following, and why? The answer, more often than not, will fit in two blocks and a silence.
The lesson for the coming cycle is subtle but decisive. Value flows where attention decides to rest, and attention, in a network of millions of participants, is the one resource that cannot be forked. Not by a client, not by a treasury, not by a whitepaper. The BIP-110 fork tried to fork attention by forking code, and attention simply looked elsewhere. That is the real warning for every project that mistakes technical conviction for social consent. The chain you fork from does not owe you its trust. It will not even remember your name. It will simply continue, block after block, keeping the quiet promise that holds the entire architecture together โ and leaving your two brave blocks behind, like a footnote the world never bothered to read.
The next real upgrade to Bitcoin will not be loud. It will arrive inside the ordinary machinery of signaling and deliberation, moving slowly enough that no single actor can claim credit for it. That is what maturity looks like. That is what the two-block fork failed to comprehend. And that is why, when the next attempt to force a blessing arrives โ and it will arrive, dressed in the newest narrative โ the networks that endure will be the ones that know how to say no while keeping the door open. The two orphaned blocks at the end of that forgotten fork are not a ruin. They are a reminder that in this industry, the ability to reject is the foundation of every ability to build.