Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Protocol History

Soft forks and hard forks, and why the difference decides who upgrades

A soft fork narrows the set of blocks a node will accept; a hard fork widens it. The distinction sounds academic until you ask who has to upgrade, because a soft fork leaves old software still following the chain while a hard fork does not. That single property explains most of Bitcoin's design choices around consensus change.

Protocol referenceSource: BIP 99 and the Bitcoin Core developer documentationThe definitions follow BIP 99's terminology for fork types.

The definition, stated precisely

Every node validates blocks against a set of rules and maintains its own view of which chain has the most accumulated proof of work. A fork is a divergence in that view, and the two kinds of rule change produce divergence in opposite directions. A soft fork adds a restriction: blocks that were valid before may become invalid, but no block that was invalid before becomes valid. A hard fork removes a restriction: blocks that were invalid before may become valid, and blocks that were valid before remain valid.

The consequence follows directly from that asymmetry. Under a soft fork, a node running the old rules will accept every block the new rules accept, because the new rules are a subset of the old ones. The old node is not wrong about the chain; it is simply unaware that some blocks it would have accepted are now forbidden. Under a hard fork, the old node will reject blocks the new rules accept, and the two sets of nodes will follow different chains.

This is why the terms are sometimes described as tightening and loosening rather than as small and large. A hard fork can be technically trivial and still be a hard fork, and a soft fork can be a substantial change to what the network does while remaining backward compatible. The category is about the direction of the rule change, not its size.

What backward compatibility means here

Backward compatibility in this context is a statement about validation, not about features. A node that has not upgraded through a soft fork continues to validate the chain correctly under the rules it knows. It will not enforce the new restriction, which means it would accept a block that the upgraded nodes reject, but as long as the miners producing blocks follow the new rules, that situation does not arise. The old node follows the same chain as everyone else.

The cost of that compatibility is that the old node's security guarantee is weaker than it believes. It is relying on the miners to enforce a rule it cannot check itself. That is a real limitation and it is the reason node operators are encouraged to upgrade even when the change is a soft fork: the point of running a node is to verify the rules independently, and a node that cannot check a rule is not verifying it.

Under a hard fork there is no such compatibility. A node that does not upgrade will reject the new chain's blocks and continue to follow the old rules, and if the two chains both attract mining power, both will continue. The result is two assets with a shared history and separate futures. That is not necessarily a failure — it is what happened in 2017 — but it is a different kind of event from a soft fork, and it requires everyone holding coins to make a decision they did not ask to make.

Why Bitcoin has preferred soft forks

The preference is not aesthetic. A soft fork can be deployed without requiring every participant to act by a deadline, which means the network does not have to coordinate a simultaneous upgrade across thousands of independent operators. The change takes effect when enough of the network enforces it, and nodes that upgrade late are not excluded in the meantime. For a system whose value depends on nobody being able to force a change on anyone else, that property is worth a great deal.

There is a second reason, which is that a soft fork cannot unilaterally take coins from anyone. Because it only removes validity, it cannot make a previously unspendable output spendable or change who is entitled to spend it. A hard fork could, in principle, and the fact that it could is precisely why the bar for one is so much higher. The conservatism is not about difficulty of implementation; it is about what the mechanism makes possible.

The preference has limits. Some changes genuinely cannot be expressed as a restriction, and a soft fork that is technically possible may still be contentious enough that deploying it would risk a split. The block size argument is the clearest case: raising the limit is a loosening by definition, so it could only ever have been a hard fork, and the disagreement about whether to do it is the subject of the block size debate page.

How a soft fork is activated

A soft fork that is never enforced by a majority of mining power is not a change to the network at all; it is a rule that some nodes apply and others do not. Activation is therefore the mechanism that turns a proposal into a rule, and it has taken several forms. The earliest soft forks used a flag day, with a block height announced in advance. Later ones used signalling in the block header, where miners indicate readiness and the change activates once a threshold is met.

The signalling approach is described in BIP 9 and BIP 8, and the version bits and soft-fork signalling page works through the thresholds and the failure modes. What matters for the soft fork distinction is that the mechanism exists precisely because a soft fork does not require universal upgrade. If it did, there would be nothing to signal about.

The deployed soft forks — Pay to Script Hash, the strict signature encoding of BIP 66, the time-lock opcode of BIP 65, SegWit and Taproot — are catalogued on the major protocol upgrades page. Each of them narrowed the valid set, and each left non-upgraded nodes following the same chain.

Sources

Related reading