FORK ME HARDER

fork around and find out

Bitcoin's rules have changed many times, and a few of those changes broke the chain in two. This is the record: what each fork actually did, who wanted it, who fought it, and how it ended. Most were routine. The interesting ones were not — and the pattern they share is that the argument was always social and the resolution was always arithmetic.

Three different things get called a fork

Most arguments about forks are people talking past each other, because one word covers three unrelated things. Separating them makes everything below easy.

The distinction that matters: a software fork is competition — a new product on a new chain. A ledger fork is secession — taking a copy of the books and leaving. A rule change is governance, and it is the only one that requires anybody else to agree with you.

Soft forks tighten, hard forks loosen

This is the whole mechanism, and it is simpler than it sounds. Every node holds a set of rules deciding which blocks it accepts. A change either shrinks that set or widens it — and which one decides whether the network survives the change intact.

SOFT FORK — tightening old rules new rules new blocks still valid to old nodes HARD FORK — loosening old new old nodes refuse the new blocks
A soft fork’s valid blocks are a subset of the old rules. A hard fork’s are not.

Soft fork — a tightening

The new rules forbid things the old rules allowed. Every block valid under the new rules is also valid under the old ones.

So a node that never upgrades keeps following along. It cannot tell anything happened: blocks arrive, they pass its checks, it accepts them.

That backwards compatibility is why nearly every change Bitcoin has made was a soft fork — P2SH, CLTV, SegWit, Taproot. It needs a majority of hashpower, because the tightening is enforced by miners refusing to build on blocks that break it.

Hard fork — a loosening

The new rules allow something the old rules forbade: bigger blocks, a different signature scheme, a changed supply.

Now the new blocks are invalid to every node that has not upgraded. Those nodes do not follow along — they reject them and keep building their own chain.

So a hard fork does not need a majority, it needs unanimity. Anyone who declines to upgrade is on a different chain by definition. Hard forks either happen by overwhelming consent, or they create a new coin.

A soft fork can still split the chain. If the miners enforcing the tightening are a minority, they reject the majority’s blocks and end up on their own short branch while everyone else carries on, never having noticed. That is exactly what happened in August 2026 — so “soft fork” does not mean “safe”.

Why changing the rules splits the chain

A node does not follow “Bitcoin”. It follows the chain with the most accumulated proof of work that is valid under the rules that node runs. Both halves of that sentence are doing work.

one chain, one history most work — keeps the name a new chain, on its own rules fork point
Shared history to the fork point, then two chains — each valid under its own rules, each invalid under the other’s.

If everyone runs the same rules, everyone computes the same answer and there is one chain. The moment two groups run different rules, “valid” means two different things, and each group follows the heaviest chain satisfying its definition. There is no vote and no referee. Two answers, two chains.

This is why nobody can change Bitcoin on your behalf. A developer can write code; a miner can mine; an exchange can list something. None of them can reach into your node and alter what it accepts. If they adopt a rule you did not, they have not changed your Bitcoin — they have left it, and you are still on the chain you were already on.

The corollary people like less: you cannot change it for everyone else either. Fork off with a rule the rest of the network does not want and you do not get a reformed Bitcoin — you get a new chain, with your rules, and whatever hashpower and users chose to come along.

The game theory of leaving

A minority chain is not merely unpopular, it is mechanically fragile — and that mechanism decides the outcome of every contentious fork.

Put together, a contentious fork resolves quickly. Either it carries enough hashpower and economic weight to sustain itself, or it stalls, its blocks slow to a crawl, and its remaining miners leave for the chain that pays. The argument is social; the resolution is arithmetic.

This is what decentralisation actually means

It is tempting to read a chain split as a failure — the network broke, the community fractured. It is closer to the opposite: the ability to fork is what makes the rules credible in the first place.

No committee can change Bitcoin’s supply, no vote can lower its difficulty, no authority can seize a coin — not because those things are forbidden, but because anyone attempting them ends up on a chain of their own while everybody else carries on undisturbed. Change the rules and you split the chain: the original continues, and your fork is a new chain that must earn its own hashpower, its own users and its own price.

That is a brutally effective defence. Capture the developers and you get a client nobody has to run. Capture a majority of miners and you get a soft fork users can refuse and a hard fork that leaves them behind. Capture the exchanges and you get a ticker on a chain with no work behind it. Every route to control ends in the same place: you may leave, you may take whoever agrees with you, and you may not take the rest.

So the timeline below is not a catalogue of disasters. It is the record of an immune response — many attempts to change the rules, a handful everyone accepted, several that left and became their own coins, and a long tail that found out precisely how much of the network agreed with them. Fork around and find out.

The timeline

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.

What keeps happening

Signalling is a declaration, not enforcement

Version-bit signalling tells you what miners say they will do. In July 2015, miners who had signalled for BIP66 built six blocks on an invalid chain because they were not actually validating. Every activation argument since has treated the gap between saying and enforcing as a live risk — and in 2026 it opened all the way: 71% of one pool's blocks had declared for the rule, and exactly one miner followed it onto the branch.

A minority chain inherits the difficulty it left with

Difficulty only retargets every 2,016 blocks. Every persistent split here — Bitcoin Cash, Bitcoin Gold, ABC/SV, BCHN/BCHA, BIP-110 — kept the difficulty of the chain it left, regardless of how little hashpower came along. It is mechanical, not political, and it is why thin forks are both slow and cheap to attack.

Replay protection is a choice, not a default

Forks deliberately creating a tradeable asset — Bitcoin Cash, Bitcoin Gold, SV — generally built it in, so a transaction signed for one chain cannot be replayed on the other. Forks that never intended two chains have none, because nobody designed for it. When one persists as two chains anyway, users are exposed with no warning in the protocol at all.

Economic weight settles it, not vote counts

Node counts, repository stars and social sentiment appear in the rhetoric of every contentious episode here and are consistently the weakest evidence offered. What settles it is which chain exchanges list, which chain people transact on, and which accumulates the most work. Node counts in particular are trivially faked and measure nothing.

Nobody agrees who decides — and that is the point

Miners point to hashrate, developers to code review, users to the software they choose to run. Every fight here re-litigates the question and none settles it, because the mechanism differed each time: SegWit activated over reluctant miners because economic nodes threatened to reject their blocks; Bitcoin Cash left regardless of what Core shipped; BIP-110 failed because the signalling its own rules required never came. No single group has ever been in charge, which is precisely why the rules have held.