Dates and block heights are marked where they could be checked against a primary source — a BIP, a release note, a mailing list post, a commit. Anything carried from secondary reporting is labelled as such, and anything that could not be pinned down says so rather than guessing.
The value overflow incident
15 August 2010block 74,638accident
A transaction created roughly 184.4 billion BTC out of nothing by exploiting a signed-integer overflow: the sum of the outputs wrapped around and came out negative, so it passed the check that outputs must not exceed inputs.
There was no BIP process yet and nothing to argue about. Jeff Garzik spotted the outsized outputs within about ninety minutes; Gavin Andresen and Satoshi Nakamoto responded directly and a patched client shipped within hours.
Outcome. The network coordinated onto the honest chain, which overtook the bad one by height 74,691. No coins were permanently created and nobody lost funds. The supply check it forced into the code is still there.
Litecoin — the software fork
October 2011software forkreported
Charlie Lee copied Bitcoin's code, swapped SHA-256 for the memory-hard Scrypt, shortened the block interval and started a brand-new chain from its own genesis block.
Not a dispute at all — nobody was trying to change Bitcoin. This is the pattern most 'forks' actually follow, and it is why the word confuses people: no history is shared, no coins are duplicated, and Bitcoin is entirely unaffected.
Outcome. Litecoin runs to this day as a separate network. Holding bitcoin never gave anyone litecoin, and no chain ever split. Dozens of coins since have followed the same recipe.
BIP16 (P2SH) versus BIP17
1 April 2012block 173,805soft forkcontentious
Pay-to-Script-Hash let a sender pay to the hash of a redeem script rather than the script itself, so the spending conditions — a multisig arrangement, say — are only revealed when the coins move.
Gavin Andresen proposed P2SH; Luke Dashjr objected to the mechanism and offered a competing design, BIP17. Two more proposals were floated in the same window. It is usually remembered as the first real ideological fight among Bitcoin's developers — the block size war in miniature, five years early.
Outcome. BIP16 shipped and BIP17 was never deployed. P2SH became foundational: most multisig, and later SegWit's backwards-compatible addresses, are built on it.
BIP30 — banning duplicate transactions
15 March 2012soft forkreported
Forbids a new transaction from reusing the exact transaction ID of an existing unspent one, which could otherwise overwrite a confirmed transaction's history and open a double-spend path.
Pure hygiene, once the failure mode was understood. It had already happened by accident: two pairs of genuinely duplicate coinbase transactions exist in the early chain and are grandfathered exceptions to this day.
Outcome. Activated without incident.
BIP34 — block height in the coinbase
March 2013block 224,413 / 227,931soft forkreported
Requires every block-reward transaction to carry its own block height as data, closing off classes of duplicate-transaction and mining-software bugs.
Proposed by Gavin Andresen as a companion to BIP30. Nobody objected.
Outcome. Activated in two stages. As a side effect it made block versioning practical, which every later signalling mechanism depends on.
The March 2013 split — and the deliberate downgrade
12 March 2013block 225,430accidentcontentious
Bitcoin 0.8.0 switched database backend from BerkeleyDB to LevelDB. BerkeleyDB had an undocumented lock limit that made certain large blocks impossible to process. Block 225,430 crossed it: 0.7 nodes rejected the block, 0.8 nodes accepted it, and the network ran as two chains for close to six hours.
Not ideological — a latent compatibility bug nobody had designed for. The resolution was the political part: rather than let the longer 0.8 chain stand, developers persuaded major pools to abandon it and reorg back onto the 0.7-compatible chain, because more of the economic network was still on 0.7. Developers and miners chose the installed base over accumulated proof of work, and both sides of later disputes have cited that precedent selectively ever since.
Outcome. The chain reorganised back within about five hours and 0.8.1 shipped with a compatibility patch. No funds were lost, though opportunistic double-spends were attempted during the window.
BIP66 and the SPV-mining split
4 July 2015block 363,725soft forkreported
BIP66 required strict DER encoding for every signature, removing a dependency on OpenSSL's inconsistent parsing that could in principle make two fully-updated nodes disagree about validity.
Nobody opposed the change. What went wrong was that roughly half the network's hashrate was 'SPV mining' — building on a block's header before validating its contents. When a non-upgraded miner produced a now-invalid block, those miners built six more on top of it without ever checking.
Outcome. The network reorganised onto the valid chain; the SPV miners lost an estimated $50,000 in orphaned rewards. It became the standing cautionary tale that signalling readiness and actually enforcing a rule are two different promises — cited constantly two years later during SegWit.
BIP65 — CHECKLOCKTIMEVERIFY
December 2015block 388,381soft forkreported
Added an opcode letting a script make an output unspendable until a given block height or time — an absolute timelock enforced by consensus rather than convention.
Routine infrastructure. No meaningful controversy.
Outcome. Activated on schedule; a building block for payment channels.
BIP68 / 112 / 113 — relative locktime
July 2016block 419,328soft forkreported
Three proposals deployed as one soft fork: relative timelocks on inputs, the CHECKSEQUENCEVERIFY opcode, and a change making absolute locktimes use the median of recent blocks rather than a miner's own timestamp.
Non-contentious technical work, deployed through BIP9 versionbits.
Outcome. Activated on schedule. These are the primitives Lightning's payment channels rest on.
The block size war: XT, Classic, Unlimited
2015 – 2017hard forkcontentiousreported
Three successive clients attempting to hard-fork the block size limit upward: Bitcoin XT (8MB, doubling every two years), Bitcoin Classic (a more modest 2MB), and Bitcoin Unlimited (remove the cap and let miners choose). None ever activated.
Big-block proponents argued Bitcoin had to scale on-chain to stay useful as payments, and that Core developers were unaccountable gatekeepers. Core-aligned developers argued larger blocks raise the cost of running a node and push toward centralisation, favouring SegWit plus off-chain scaling — and that no single client or company should be able to change Bitcoin's rules by fiat. Both readings are still widely held; this page does not adjudicate between them.
Outcome. None became Bitcoin's ruling client. XT's activation threshold was never reached; Mike Hearn declared 'Bitcoin has failed' and left in January 2016. The argument was settled instead by SegWit and by the Bitcoin Cash secession.
The Hong Kong Agreement
21 February 2016hard forkcontentiousreported
Not code — a roadmap. Core developers and major miners agreed that SegWit would be prioritised as a soft fork, to be followed within months by a 2MB hard fork.
Miners say Core signed and then never delivered the hard fork, treating the miners' half as binding and their own as aspirational. Core-aligned developers say they agreed only to propose and pursue it, that no individual can force a change onto a decentralised network, and that continued disagreement over the design — not bad faith — is why it never shipped. Nobody disputes that the second half never happened.
Outcome. No 2MB hard fork was delivered. The unresolved tension fed directly into SegWit2x a year later.
SegWit — the centrepiece
24 August 2017block 481,824soft forkcontentious
Segregated Witness moved signature data outside the part of a transaction that determines its ID, fixing transaction malleability and — as a side effect — raising effective capacity by discounting witness data.
Deployed through BIP9, needing 95% of blocks to signal. Signalling stalled between 30% and 44% for most of 2017. One widely discussed and still-contested explanation is that some miners were using an optimisation called ASICBOOST whose most efficient form was incompatible with SegWit — making activation directly costly to them, separately from any stated policy view. Then two things broke the deadlock: BIP148, a user-activated soft fork committing node operators to reject non-signalling blocks from 1 August regardless of miners, and BIP91, which lowered the bar to 80% and orphaned non-signalling miners before BIP148's deadline could be tested.
Outcome. SegWit activated cleanly and is part of the base rules today. It remains the reference case for the argument that economic nodes, not miners, hold final authority — because the threat of BIP148 never had to be carried out.
The New York Agreement and SegWit2x
Signed May 2017, cancelled 8 November 2017block planned ~494,784, never reachedhard forkcontentiousreported
Roughly 58 companies and mining pools agreed to activate SegWit and then hard-fork to 2MB blocks within about three months. The second half, 'SegWit2x', was implemented in a client called BTC1.
Controversial less for the size increase than for how it was made: negotiated by a small group of companies and miners outside the open development process, which critics characterised as an attempted corporate takeover of Bitcoin's governance. As the date approached, replay protection was contested and prominent voices on both the small- and big-block sides came out against it.
Outcome. Cancelled by its own organisers for lack of consensus. No SegWit2x hard fork ever took place.
Bitcoin Cash — the first lasting secession
1 August 2017block 478,558hard forkcontentious
A hard fork raising the block size limit to 8MB and rejecting SegWit outright — the opposite direction to the path Bitcoin had taken days earlier. It included two-way replay protection via a new signing rule, so a transaction valid on one chain is deliberately invalid on the other.
Built by the Bitcoin ABC team with mining support from Bitmain and ViaBTC, and championed publicly by Roger Ver. Backers argued SegWit plus an undelivered 2MB fork was not the on-chain scaling Bitcoin needed, and that Bitcoin Cash represented the original peer-to-peer-cash vision — the 'real Bitcoin' framing that still fuels the naming dispute. Opponents argued bigger blocks trade node decentralisation for capacity, and that the launch was a rejection of the process itself.
Outcome. Survives as an independently traded chain with its own fork history — it has since split twice more. This is the textbook ledger fork: shared history to 478,558, nothing shared after.
Bitcoin Gold
24 October 2017block 491,407hard forkcontentiousreported
Replaced SHA-256 with Equihash, a memory-hard algorithm meant to resist the specialised hardware that dominates Bitcoin mining, with the stated aim of returning mining to GPU owners.
Founded by Jack Liao, whose company sold ASIC-resistant mining hardware — which critics used to argue the framing was self-interested. A roughly 0.5% pre-allocation to the founding team drew accusations of a pre-mine.
Outcome. In May 2018 its thin hashrate made it a target: attackers 51%-attacked the chain and double-spent a reported $18M against exchanges. A concrete demonstration of the security a minority-hashrate fork gives up.
Bitcoin Diamond and the 2017–18 fork wave
24 November 2017block 495,866hard forkreported
A hard fork to 8MB blocks and a different mining algorithm, whose headline feature was a 1:10 airdrop — every bitcoin held at the fork block entitled the holder to ten BCD.
Built by two anonymous teams. It was one of roughly nineteen Bitcoin-derived forks in 2017 alone, with commentators projecting fifty more. The recipe was consistent: snapshot the UTXO set, add a headline feature, airdrop a token to existing holders.
Outcome. Almost the entire wave persists only as thinly traded tokens, if at all. Several shipped weak or absent replay protection, putting their own users at risk of spending coins on both chains unknowingly.
CVE-2018-17144 — the inflation bug
Disclosed 20 September 2018accident
An optimisation added in 0.14.0 skipped a check for a transaction spending the same input twice. In 0.14.x this crashed the node. In 0.15.0 through 0.16.2 a rewrite changed the failure mode: an affected node could accept a block containing such a transaction, allowing coins to be spent — or created — more than once.
Reported privately as a mere denial-of-service issue, and shared simultaneously with other projects on the same codebase. Reviewers working on the patch independently realised the underlying problem was far worse before the fix shipped.
Outcome. Patched before public disclosure. There is no evidence it was ever exploited. It is remembered as the near-miss that justifies continuous funded review of consensus code.
The hash war — Bitcoin Cash splits into ABC and SV
15 November 2018block 556,766 / 556,767hard forkcontentiousdate uncertain
A hard fork inside Bitcoin Cash. Bitcoin ABC proposed canonical transaction ordering and a new opcode; Bitcoin SV, built by nChain under Craig Wright, rejected them, proposed 128MB blocks and sought to restore removed opcodes.
The most openly militarised fork in the family. Wright framed it as a fight over which chain was the true Bitcoin Cash and promised a 'hash war' — both sides pointing hashrate at their preferred chain to outweigh the other rather than to mine profitably. Reported estimates put the cost in the tens of millions.
Outcome. ABC's chain kept the Bitcoin Cash name and ticker; SV continued separately. Sources give both 556,766 and 556,767 for the first divergent block depending on which chain is meant, and this could not be resolved to one figure.
Bitcoin Cash splits again — BCHN and BCHA
15 November 2020block 661,648hard forkcontentiousreported
Another hard fork within Bitcoin Cash, over Bitcoin ABC's plan to redirect about 8% of the block reward to a development fund it controlled — a protocol-enforced tax on miners to pay one team.
Opponents framed it as a development team entrenching itself financially by fiat rather than by donation. Structurally the same governance dispute as the ABC/SV fight, with ABC this time on the losing side of a split it had itself proposed.
Outcome. BCHN took the large majority of miner signalling and kept the name, ticker and trading history. The minority chain continued as BCHA — with no replay protection between the two.
eCash — the BCHA rebrand
1 July 2021software forkreported
Not a split: the minority chain from the 2020 fork renamed itself eCash, converting balances at a million to one and adding an Avalanche consensus layer over its proof-of-work base.
Included here because it shows how far a lineage can travel. Bitcoin to Bitcoin Cash to Bitcoin ABC to eCash is three splits removed from Bitcoin, and by this point the technical design has little in common with what it left.
Outcome. Trades independently as XEC.
Taproot
14 November 2021block 709,632soft forkreported
Three proposals as one soft fork: Schnorr signatures, which are smaller and can be aggregated; Taproot proper, letting a single output represent either a simple spend or a complex script while making the common case indistinguishable on-chain; and Tapscript, the updated scripting language for the complex path.
Activated by 'Speedy Trial' — a short window needing 90% miner signalling, with a fixed minimum activation height. The one real argument was about what should happen if it failed: Luke Dashjr and others wanted BIP8 with LOT=true, guaranteeing activation on a date regardless of miners, the same philosophy as BIP148. Most developers preferred no forced fallback. The same fault line SegWit exposed, at a fraction of the temperature.
Outcome. Locked in on its own and activated cleanly. No split, and the fallback client was never needed.
BIP-110 (RDTS) — the mandatory-signalling split
8 August 2026block 961,631 (last shared block)soft forkcontentious
A temporary soft fork capping the data a transaction could carry — output scripts, OP_RETURN payloads, witness items — aimed at inscriptions and token protocols, and designed to expire after about a year. Voluntary signalling never came close: it peaked at 51 of 2,016 blocks, 2.53%, against a 55% threshold. So it fell to mandatory signalling, where from block 961,632 an enforcing node rejects any block that does not signal.
Proponents treated arbitrary data as spam that a temporary rule could curb. Opponents treated the fees that data pays as legitimate revenue, and mandatory signalling as coercion dressed as a vote. In practice the opposition was simply every major pool declining to signal.
Outcome. AntPool mined a non-signalling 961,632; enforcing nodes rejected it and built their own. The enforcing branch produced two blocks, stalled for days, resumed briefly, and reached only 961,637 by 21 August — while the majority chain passed 963,478. There is no replay protection, because a split was never the intended outcome. This site's operator watched it happen live, on nodes that no longer run; the heights are public and checkable on any explorer.