Soft forks and hard forks: how Bitcoin changes its rules without a boss

A fork is a disagreement about which blocks count

Every Bitcoin node, meaning a computer running the software and checking every block for itself, applies a set of rules: how big a block may be, what makes a signature valid, how many new coins a miner may claim. Those are the consensus rules. Nodes that agree on them will agree on the chain. Change the rules on some nodes and not others, and you have a fork: two groups of computers that may no longer accept each other’s blocks.

The word gets used two ways, which causes confusion. A fork can mean a rule change, proposed and deployed on purpose. It can also mean a chain split, where the network temporarily or permanently follows two different histories. Rule changes can cause splits, but so can bugs; BIP 99 calls that an “accidental consensus fork,” and the consensus incidents dossier covers the accidental kind. This article is about the deliberate kind, and the two words that describe them.

BIP 123, a 2015 proposal by Eric Lombrozo that sorts Bitcoin proposals by layer, gives the cleanest definitions. It puts consensus changes in the lowest layer, the one where everyone has to agree, and defines both kinds of fork in a sentence each.

A soft fork adds restrictions that older nodes do not enforce

BIP 123: “In a soft fork, some structures that were valid under the old rules are no longer valid under the new rules. Structures that were invalid under the old rules continue to be invalid under the new rules.” The set of valid blocks shrinks. Because every block that satisfies the new, stricter rules also satisfies the old ones, a node that never upgraded still accepts the chain. It simply does not know why the miners have stopped doing certain things.

Jorge Timón’s BIP 99, from the same year, explains why this is backward compatible in one line: “For old nodes it just looks like the new rules are policy rules rather than consensus rules.” Policy is what a node chooses to do; consensus is what it must do. To an old node, a soft fork looks like miners being picky. BIP 99 also notes the flip side: “A hashrate majority of miners can impose the new rules,” because if most blocks follow them, blocks that break them get orphaned.

One consequence, from the Bitcoin Wiki’s softfork page: a soft fork cannot be undone with another soft fork, because a soft fork can only shrink the set of valid blocks, never grow it back. Reversing one needs a hard fork.

A hard fork can produce blocks that older nodes reject

BIP 123 again: “In a hard fork, structures that were invalid under the old rules become valid under the new rules.” Now the set of valid blocks grows. A node running old software sees a block that breaks a rule it still enforces, rejects it, and keeps following whatever chain obeys the old rules. If some miners produce old-rule blocks and some produce new-rule blocks, the network splits into two coins with a shared past and different futures. BIP 99’s definition ends with the operational fact: “Hardforks require all users to upgrade.”

BIP 99 sorts hard forks by intent. An uncontroversial hard fork has broad agreement and a distant activation height so everyone has time. A “schism” hard fork is a deliberate split, where one group wants a different Bitcoin than the other. And an emergency hard fork is what you do when a bug leaves no better option. The proposal’s deployment advice differs for each. The point is that a hard fork is not automatically bad, but it always demands coordination that a soft fork does not.

Three soft forks that shipped: P2SH in 2012, SegWit in 2017, Taproot in 2021

Pay to Script Hash, BIP 16, was written by Gavin Andresen and dated 3 January 2012. It let a payment go to the hash of a script rather than the script itself, which is what makes multisignature addresses practical. Old nodes checked only that the hash matched and did no further validation, so they accepted the new transactions. Deployment was by miner signal: miners put “/P2SH/” in the coinbase of their blocks, and the plan was to count them on 1 February 2012, with 550 tagged blocks in a week, about 55 percent, as the threshold. The final text applies the new rules to blocks timestamped from 1 April 2012.

Segregated Witness, BIP 141, was proposed on 21 December 2015 by Eric Lombrozo, Johnson Lau and Pieter Wuille. It moved signatures out of the part of the transaction that old nodes examine, and replaced the 1 MB block size limit with a block weight limit of 4,000,000 units. The soft-fork trick was that old nodes see the new outputs as “anyone-can-spend,” which they had always treated as valid, so they accept blocks they cannot fully check. Signaling used BIP 9 version bits from 15 November 2016, and after the long fight told in the block size war dossier, SegWit activated in August 2017. Our SegWit explainer goes into what changed for users.

Taproot, BIP 341, by Pieter Wuille, Jonas Nick and Anthony Towns, dated 19 January 2020, added Schnorr signatures and a new output type. It used the same anyone-can-spend pattern: non-upgraded nodes treat the new outputs as spendable by anyone and are “strongly encouraged to upgrade.” Miners signaled between April and August 2021 at a 90 percent threshold, 1,815 blocks in a signaling period, and Taproot activated at block 709,632 on 14 November 2021. See Taproot explained.

One hard fork that split the chain: Bitcoin Cash, 1 August 2017

The clearest example of a hard fork is the one that created Bitcoin Cash. Its technical specification, called the User-Activated Hard Fork or UAHF, set activation by median block time at the Unix timestamp 1501590000, which is 1 August 2017 at 12:20 UTC. The first block after activation had to be larger than 1,000,000 bytes, the very thing Bitcoin’s rules forbade, and the new chain accepted blocks of up to 8 MB. That single rule guaranteed that Bitcoin nodes would reject the fork block and that the two chains could never rejoin.

The specification also added replay protection: transactions on the new chain had to be signed with a flag, SIGHASH_FORKID, that Bitcoin nodes do not recognize, so a transaction meant for one chain could not be copied onto the other. Anyone holding bitcoin at the fork held equal amounts on both chains afterwards. Our article on the Bitcoin Cash fork tells the story, and the block size war dossier explains the dispute that led there.

Who decides? Miners signal, but nodes and users choose

A soft fork is often described as “activated by miners,” and miner signaling has been the usual mechanism since BIP 16. But signaling is a coordination tool, not a vote on whether the change is good. A rule that miners enforce and users reject leaves miners producing blocks nobody values. BIP 99 has a name for that, a “unilateral softfork,” and lists it among the things to avoid. The real gate is whether the people running nodes and holding coins upgrade and keep following the chain.

That is why the process starts with a written proposal rather than a code push. Every fork discussed here began as a Bitcoin Improvement Proposal, argued over in public, and adopted only once enough of the network chose to run it.

Test compatibility with a block that separates the two rule sets

Imagine that old rules accept blocks A and B, while a proposed restriction accepts only A. A is valid under both sets of rules; an older node may still accept B even though an upgraded node rejects it. This is the central compatibility issue in a soft fork, not a claim that old software enforces the new restriction.

Now imagine a change that permits a block C which the old rules reject. An old node cannot simply accept C because more miners produce it. Whether this incompatibility becomes a lasting split also depends on whether participants continue maintaining both histories. Use these validity questions before describing the political outcome of a fork.