Bitcoin’s 2015-2017 fork wars produced four hard-fork attempts on the main chain (Bitcoin XT, Bitcoin Classic, Bitcoin Unlimited, SegWit2x) and one chain split that survived (Bitcoin Cash, August 1, 2017). Two adjacent analyses cover what those events were and what naming did to them: the fork and altcoin genealogy records the event sequence, and the Bitcoin Core rebrand authority-effects analysis reads the lexical asymmetry the 2014 rename introduced. This entry asks a third question those two do not directly take on: why did each of these events run as a political and economic contest, not as an ordinary open-source disagreement?
The reading offered here is structural. Three conditions present in 2014-2017 Bitcoin — a vacuum of designated authority, the economic weight that had accumulated on rule decisions, and a three-layer separation between the protocol, the software, and the live currency network — together made it structurally impossible for a disagreement on a load-bearing parameter to remain a software question. The naming asymmetry covered in the rebrand analysis is the lexical instrument by which these conditions expressed themselves. The conditions themselves are what this entry reads.
1. The vacuum after April 2011 (the precondition, not the result)
A common reading places Satoshi’s departure inside the war’s emotional shape — “no wonder he left, with all this fighting.” The chronology says the opposite:
| Date | Event |
|---|---|
| April 23, 2011 | Final Satoshi email to Mike Hearn |
| April 26, 2011 | Final Satoshi email to Gavin Andresen (alert-key handover) |
| 2011-2014 | Codebase maintained by Andresen and a small group; no major disputes |
| December 16, 2013 | Bitcoin Core rebrand merged |
| August 15, 2015 | Bitcoin XT launched — the public phase of the war begins |
| August 1, 2017 | Bitcoin Cash chain split |
Satoshi left more than four years before the public-fork phase opened. The dispute did not drive him away; the dispute happened in the structural void his absence had already created. (For one reading of why Satoshi left, see Hearn’s 2025 CoinGeek retrospective on the BitcoinTalk evangelical pressure of late 2010 — that dynamic is separate from what came after 2014.)
There was no public successor announcement, no legal entity holding the project, and no formal handover document. The closest thing to a handover, on Hearn’s later account, was ad-hoc:
“When Satoshi left, he handed over the reins of the program we now call Bitcoin Core to Gavin Andresen, an early contributor. … Only one tiny problem: Satoshi never actually asked Gavin if he wanted the job, and in fact he didn’t.”
— Mike Hearn, “The resolution of the Bitcoin experiment” (January 14, 2016)
Andresen’s lead-maintainer announcement (December 19, 2010) preceded Satoshi’s silence by four months and was scoped to the codebase, not the protocol. After 2011 the codebase had a maintainer; the protocol had no one. The Bitcoin Foundation (founded September 2012) attempted that role and collapsed financially by 2015. The codebase maintainers (Andresen, then Wladimir van der Laan from April 2014) were de facto deciders, but their authority was conventional, not designated.
This is the precondition that everything else fills. The naming asymmetry, the economic weight, and the three-layer structure are what flowed in.
2. The money on top by 2014-2015
By the time of the Bitcoin XT launch (August 15, 2015), Bitcoin’s economic surface had grown well past anything resembling a hobby project:
- Price. Approximately $230 in August 2015, with prior peaks above $1,000 in late 2013.
- Mining. ASIC hardware had displaced GPU and CPU mining. Bitmain (founded October 2013, Jihan Wu co-founder) was the dominant ASIC manufacturer. Mining had become an industrial activity — capital-intensive, geographically clustered, and economically dependent on rule continuity.
- Exchanges and custody. Major exchanges (Bitfinex, Coinbase, Kraken) carried institutional flow. Custody services protected significant balances; BitGo (founded 2013, Mike Belshe CEO, later a 2017 SegWit2x signatory) was a representative example.
- Corporate orbit on the conservative side. Blockstream (founded November 2014, co-founded by Adam Back, Gregory Maxwell, Pieter Wuille, Jorge Timón, Matt Corallo, and others) employed several Bitcoin Core contributors on a research-and-tooling agenda (sidechains, Lightning, Liquid).
- Corporate orbit on the larger-block side. Roger Ver’s bitcoin.com was the most visible commercial property aligned with the larger-block faction. Bitmain’s hashrate position aligned commercially with on-chain scaling. Later, nChain (Calvin Ayre, Craig Wright) provided the corporate base for the BSV split.
When a load-bearing parameter (block size, fee market, soft-fork activation policy) is debated under these conditions, “purely technical” judgment is no longer separable from revenue, hashrate alignment, and asset valuation. Each side could point to a coherent technical argument, and each side’s coherent technical argument also happened to align with its commercial position. That alignment is not by itself a disqualification — it is what happens when a project becomes economically large. It does, however, remove the assumption that participants were arguing only about what was technically right.
3. The three layers that bind
This is the conceptual point that distinguishes Bitcoin from an ordinary open-source project. Three things share the name “Bitcoin”:
| Layer | What it is |
|---|---|
| Protocol | The consensus rules — block format, signature validation, the longest-chain rule, the 21 M cap |
| Software | The reference client (Bitcoin Core), and any alternative implementation (XT, Classic, Unlimited, ABC, etc.) that agrees with the protocol |
| Network / currency | The live chain operating under those rules — every node, miner, exchange, holder, and payment processor that has adopted a given rule set |
In ordinary OSS the three collapse: the project, the software, and the deployed thing are co-extensive. Forking the codebase creates an alternative implementation; it changes nothing else. A Spring fork is a Spring fork. A Ruby fork is a Ruby fork. The brand and the user base do not transfer; the original keeps its identity, and the fork starts fresh with whatever audience it can build.
In Bitcoin the three are separable in principle but bound in practice. The protocol is defined by what nodes accept; the software encodes that protocol; the live currency operates wherever the rules are jointly upheld. Forking the codebase to run a different rule set means leaving the live currency network — losing access to the existing chain’s hashrate, exchange listings, address scheme, ticker, and brand. Staying on the live network with the same rule set is, by 2014 vocabulary, to be “Bitcoin Core” or compatible. There is no analogue, in conventional OSS, of a fork that retains the brand and the user base while diverging from the canonical maintainer’s choices. The cost of disagreement is unusually high.
This is why each of the 2015-2017 forks needed to claim it was Bitcoin. Bitcoin XT, Bitcoin Classic, Bitcoin Unlimited, Bitcoin Cash all did. The claim was not vanity. It was a structural requirement for attracting liquidity, hashrate, exchange listings, and brand recognition. A fork that had publicly conceded the name “Bitcoin” would have launched at a marked structural disadvantage on each of those axes — not impossible to sustain, as the existence of independently-named cryptocurrencies shows, but materially harder to compete with the original chain on its own terms.
4. The three conditions in combination
Each of §1-§3 alone is partial. The vacuum alone produces a leadership question. Money alone produces normal lobbying. The three-layer structure alone produces the technical observation that protocol ≠ software ≠ network. Stacked, they produce the specific shape of the 2015-2017 wars:
- The vacuum means there is no body authorized to settle the question on behalf of Bitcoin.
- The money means each side has skin in the game and cannot fully separate technical judgment from commercial position.
- The three-layer structure means a technical fork is also an identity fork — to disagree on rules is to fight over what counts as Bitcoin.
The naming asymmetry that the rebrand analysis documents is the lexical instrument these conditions reached for. The choice of “Bitcoin Core” in 2014 weighted the available vocabulary in one direction, but a different name in 2014 would not have changed the underlying structure. Whatever the central client had been called, the contested object would still have been the name “Bitcoin” — because that is where the network, the hashrate, and the money lived. Hearn’s framing in his 2016 departure essay (“Bitcoin has failed,” not “the larger-block faction has failed”) and the BCH / BSV camps’ “real Bitcoin” rhetoric are not stylistic excess. They are what the structure required participants to say.
This also explains a feature of the war that observers from ordinary OSS find puzzling: there was no neutral way to lose. In an ordinary fork, the losing side simply runs its own project at smaller scale and gets on with life. In Bitcoin, the losing side either had to abandon the rule set entirely or take a hashrate share, exchange listings, and a separate ticker on a chain that could not call itself Bitcoin in mainstream usage. None of the four 2015-2017 hard-fork attempts secured the original ticker. That outcome is consistent with the structural reading: the contest was over the name and the network, not just over the rules.
5. The boundary of this reading — those who built new instead of forking
The conditions in §1-§4 explain why those who chose to fork ran as they did. They do not claim to explain everyone who disagreed with Bitcoin’s direction during 2013-2014. A small number of people in that period built new chains from scratch rather than forking — they sat outside the population this entry’s reading applies to. The clearest case is Vitalik Buterin.
Buterin was deeply embedded in the Bitcoin community by the time the fork wars began. At 17 he discovered Bitcoin (2011); at 19 he co-founded Bitcoin Magazine with Mihai Alisie (May 2012, the community’s first print magazine); through 2013 he wrote extensively for the Magazine, contributed widely-used software (pybitcointools), and advocated extending Bitcoin’s scripting language to support Turing-complete computation, primarily through the Mastercoin team. The Bitcoin developer community did not converge on accepting the extension.
His response was not to fork. In late 2013 he wrote the Ethereum white paper. On January 26, 2014, at the North American Bitcoin Conference, he announced Ethereum publicly. The mainnet went live on July 30, 2015 — sixteen days before Bitcoin XT launched. When the public-fork phase of Bitcoin’s block-size war began, Ethereum was already a live, operating chain with its own community.
A partial parallel exists in Daniel Larimer. Larimer was active on BitcoinTalk in 2010-2013, challenged Satoshi on transaction-confirmation speed in the ‘Scalability and transaction rate’ thread, and received Satoshi’s famous brush-off: “If you don’t believe me or don’t get it, I don’t have time to try to convince you, sorry.” Larimer subsequently built BitShares (2014), Steem (2016), and EOS (2018). Same pattern: engaged with Bitcoin community → ideas not accepted → built new designs from scratch.
The point of recording these cases is not to rank them against fork-war participants on capability. Mike Hearn left a senior Google engineering role to commit to Bitcoin full-time. Gavin Andresen was Bitcoin’s lead maintainer for years. Pieter Wuille and Amaury Séchet were both credentialed protocol engineers. The point is that the goals were different. Hearn wanted bigger blocks on Bitcoin, not smart contracts replacing Bitcoin’s monetary design. Andresen wanted Bitcoin’s parameters set as he believed correct. The BCH and BSV camps wanted Bitcoin’s economics reshaped to fit their commercial models. Each of those goals required staying with Bitcoin’s codebase, which means a fork. Buterin and Larimer wanted a system whose design was not Bitcoin’s. That goal required a new chain.
This locates the boundary of §1-§4’s reading. The vacuum, the money, and the three-layer structure produce fork wars in the population whose goal is to change Bitcoin while keeping it. Those whose goal was to build something genuinely new sat outside that population. Recording the boundary clarifies what the reading does and does not cover. It does not extend the reading to cover them.
6. What stays open
Three counter-readings deserve explicit acknowledgement.
(a) “The forks lost on technical merit.” A defensible position is that BIP 101’s 8 MB-doubling schedule, BCH’s 8 MB initial cap, and BSV’s 128 MB cap were each technically wrong on their own terms — that mining-centralization risk, propagation latency, and node-operability concerns were real and load-bearing. This reading is not in conflict with §1-§4. The structural conditions described here did not determine which side was technically right; they determined that whatever the technical answer, the contest would run as an identity contest. Both readings can be true simultaneously.
(b) “The conservative side was a Blockstream operation.” A frequently-asserted reading among large-block partisans is that Blockstream’s research agenda (SegWit, Lightning, off-chain layers) drove the main-chain stance, and that this constituted corporate capture. The documentary record supports the staffing fact — several Bitcoin Core contributors were Blockstream employees — but does not, by itself, support the capture claim. Technical positions are not invalid because their authors are paid. The same skepticism applies in mirror: Bitmain’s hashrate position and bitcoin.com’s branding position aligned with their commercial interests in larger blocks. Neither side’s positions are voided by their funding; neither side’s positions were free of it.
(c) “Bitcoin is just OSS, the fork-as-leaving framing is wrong.” Under this reading, every fork is a software fork like any other, and the ones that gained share are the ones whose technical decisions held up. This reading is internally consistent and is the one that sounds correct to most software engineers approaching the topic for the first time. It does not, however, explain why the participants themselves — including Hearn writing in 2016 and 2025 — repeatedly framed the events in terms of identity, authority, and naming rather than in terms of software. The participants’ own framing is part of the documentary record; a reading that has to dismiss it as confusion has done less work than a reading that takes it as evidence.
The reading in §1-§4 is offered as one reading. It claims only that the participants’ own framings — authority, naming, vacuum, identity — describe a real load on top of the code, not a misperception of an ordinary OSS dispute.