Soft Fork & Hard Fork - Two Ways to Change the Rules

There is no company that can press an update button for Bitcoin. And yet SegWit and Taproot were actually deployed. How does a system with no owner change its rules? The answer is soft forks and hard forks.

The difference fits in one sentence. A soft fork narrows the rules; a hard fork widens them. That single difference in direction decides whether the chain stays whole or splits in two.

What the Consensus Rules Are

When a node receives a block, it checks it against a list of rules one by one. Is the block weight within the limit? Are the signatures valid? Is the issuance exactly what it should be? Is anything spending an output that was already spent? That list is the consensus rules.

What matters here is not the rules themselves but that they must be the same for everyone. If a block my node considers valid is rejected by yours, the two of us are already using different currencies. This is why protocol changes are delicate. Editing the code is not the hard part; keeping tens of thousands of nodes worldwide reaching the same verdict is.

So a rule change is classified not by what it changes but by whether old nodes still accept the new blocks afterwards.

graph TB
  A["Block made under new rules"] --> B{"Verdict of an<br/>un-upgraded old node"}
  B -->|"Soft fork<br/>passes the old rules"| C["Accepted<br/>one chain remains"]
  B -->|"Hard fork<br/>violates the old rules"| D["Rejected<br/>chain splits in two"]
  style C fill:#3fb950,stroke:#3fb950,color:#000
  style D fill:#f85149,stroke:#f85149,color:#000

Soft Fork: Narrowing the Rules

A soft fork makes some of what used to be valid invalid. The set of blocks valid under the new rules becomes a subset of the set valid under the old ones.

In this direction, a node that has not upgraded still accepts new blocks without trouble, because a block that satisfies the new rules automatically satisfies the old ones. This is why a soft fork is called backward compatible, and why the network does not split even when not everyone upgrades at once.

A natural question follows. If the rules only ever narrow, how does anything new get added? Bitcoin sidesteps this cleverly. It takes space that looks to old nodes like "anyone-can-spend" and gives it a strict meaning that only new nodes enforce.

SegWit and Taproot were introduced exactly this way. An old node looks at a SegWit output, concludes "that output is spendable without conditions," and lets it through, while an upgraded node enforces the stricter condition that a valid signature is required. From the old node's point of view nothing has been violated, so there is nothing to reject.

It is not free, though. An old node cannot validate the new rules, so with respect to that part it ends up trusting miners. A soft fork trades a little validation sovereignty for an upgrade with no downtime. Which is why, even for a soft fork, upgrading your own node is still the right move.

One more thing. For a soft fork to be safe, a majority of hashrate must enforce the new rules. If only a minority enforces them, their blocks get orphaned by the longer chain. That is why activation waits on miner signalling.

Hard Fork: Widening the Rules

A hard fork makes something that used to be invalid valid. Raising the block size limit from 1MB to 8MB, changing the 21 million supply cap, or adding a new opcode to Script all belong here.

In this direction, old nodes necessarily reject the new blocks. To a node that knows a 1MB limit, a 4MB block is simply a rule violation. There is no room for persuasion or negotiation. The software is written to reach that verdict, and it does.

graph TB
  B0["Block N-1"] --> B1["Block N<br/>(last common block)"]
  B1 --> C1["Block N+1<br/>new-rule chain"]
  B1 --> D1["Block N+1<br/>old-rule chain"]
  C1 --> C2["new-rule chain continues"]
  D1 --> D2["old-rule chain continues"]
  style B1 fill:#f7931a,stroke:#f7931a,color:#000
  style C2 fill:#58a6ff,stroke:#58a6ff,color:#000
  style D2 fill:#8b949e,stroke:#8b949e,color:#000

The result is a chain split. Unless one side quietly dies, two ledgers grow separately, producing two coins that share a transaction history up to the point of divergence. When Bitcoin Cash split off in 2017 and existing holders found an equal amount of a new coin, that was not magic but this. Outputs from before the split are written identically in both ledgers.

So a hard fork only works if effectively everyone upgrades at the same time. The coordination cost is overwhelming, and failed coordination splits the money itself.

Why Bitcoin Insists on Soft Forks

Technically, a hard fork is often the cleaner option. You can simply write the rule you want, without convoluted workarounds like SegWit's witness discount. And yet every protocol change since 2017 has been handled as a soft fork. The reason is not technical but a question of power.

A hard fork gives users no choice. Fail to upgrade and you are dropped from the network, so in practice it is comply or leave. Repeat that pattern and whoever proposes the rules can drag everyone else along. In a system where forced upgrades are routine, a promise like the supply cap stops being "the thing that cannot change" and becomes "the thing not yet changed."

Under a soft fork, by contrast, someone who disagrees can stay on the old software. The veto stays in individual hands, and the side pushing the change has to persuade the opposition. Bitcoin changing slowly is not a defect; it is what this structure is designed to produce.

How Activation Works

Deciding on a rule does not turn it on. You also have to decide when it starts being enforced.

BIP9 version bits let miners signal approval through the version field of the block header, locking in when more than 95% of a 2016-block period signals. SegWit attempted this route.

A UASF (user activated soft fork) does not wait for miner signals. Nodes declare in advance that from a given date they will reject blocks that fail to follow the new rules. BIP148 in 2017 is the example, remembered as the moment that showed final authority rests with economic nodes rather than miners.

Speedy Trial was the compromise used for Taproot. It set a short window of about three months requiring 90% signalling within a difficulty period, and let the attempt expire quietly if it failed. The design aimed to keep the activation debate from becoming another war, and Taproot did lock in during June 2021 and activate at block 709,632 that November.

Real Cases

P2SH (2012, BIP16) is the classic early soft fork, using a slot that old nodes read as an unconditional output to introduce script hashes. CLTV (2015, BIP65) and CSV (2016, BIP112) added timelock opcodes and laid the groundwork for the Lightning Network. SegWit (2017, BIP141) and Taproot (2021, BIP341) are soft forks as well.

The example of an intentional hard fork is Bitcoin Cash on 1 August 2017, which raised the block size to 8MB and permanently separated the chain.

There has also been one unintentional hard fork. In March 2013, version 0.8 changed the database layer and produced a block that exceeded a lock limit which existed only in older versions, splitting the chain around block 225,430. The episode revealed that consensus rules are not sentences written in a specification but the behaviour of the implementation that actually runs. Even an undocumented database setting turned out to be part of the consensus rules.

Common Misconceptions

One is that a fork means new coins. A soft fork creates no coins. New coins appear only when a chain actually splits and both sides survive, and even then it is not issuance but a copy of the existing ledger.

Another is that miners set the rules. Miners only choose which blocks to build; nodes decide whether those blocks are valid. A block that breaks the rules is rejected no matter how much proof of work went into it. That is precisely what the 2017 UASF demonstrated.

Finally, a chain split and a reorg are different things. A reorg is a temporary event under a single rule set where a longer chain appears and the shorter one is discarded, while a hard fork split is a state in which the rules themselves differ and each chain regards the other as permanently invalid.

Related Concepts

• SegWit - the definitive soft fork built on an anyone-can-spend slot
• Taproot - the most recent soft fork, activated via Speedy Trial
• Node - what actually enforces the rules and decides how a fork ends
• Mining Pools - the role miners play in activation signalling
• 21 Million Cap - the supply limit that cannot change without a hard fork