Timechain Wiki

Soft forks and hard forks

12 min read

Bitcoin's protocol can change in two structurally different ways. A soft fork tightens consensus rules — adding constraints that make some previously-valid blocks invalid; old nodes still accept new blocks, so soft forks are backward-compatible and upgrade the network incrementally without splitting. A hard fork changes rules so that new blocks are invalid under old rules — non-upgraded nodes reject the new chain, so hard forks require unanimous upgrade or the network splits. Bitcoin has activated soft forks every few years (notably SegWit 2017 and Taproot 2021); it has had effectively zero coordinated hard forks in 17 years, both from a strong cultural preference for backward-compatibility and because hard forks are politically near-impossible at scale. The 2017 Block Size Wars demonstrated definitively that disputed hard forks produce chain splits, not protocol changes — Bitcoin Cash split off and Bitcoin proper continued unchanged. Contemporary protocol-evolution debates (post-quantum migration, OP_CAT covenants, BIP-300 sidechains) are debates over whether specific soft forks should activate.

Why this note matters

The mechanism by which Bitcoin’s consensus rules change is one of the protocol’s most important — and most contested — design choices. Bitcoin’s combination of strong soft-fork preference and practical impossibility of hard forks shapes everything: what kinds of upgrades are possible, how long they take, what political coalitions are required, and what protocol designers can realistically propose.

Understanding the soft-fork / hard-fork distinction is essential for engaging contemporary protocol debates substantively. The questions “Should OP_CAT be re-enabled?”, “Should the block weight increase?”, “Should Bitcoin add post-quantum signatures?” all ultimately become “Can this be done as a soft fork, and if so, can it get sufficient miner and user support to activate?”

Soft forks: tightening the rules

A soft fork narrows the consensus rule-set. Before the fork, blocks satisfying the old rules are valid. After the fork, blocks must satisfy the old rules plus one or more new constraints. Examples:

  • BIP-66 (2015): Strict DER signature encoding. Before: any DER-ish encoding accepted. After: only canonical DER encodings accepted. Old nodes still accept canonical DER (it was always valid).
  • SegWit (2017, BIP-141): New address types with witness-segregated data. New blocks that use SegWit are valid under both old and new rules (the witness data is invisible to old nodes but doesn’t violate anything).
  • Taproot (2021, BIP-341): New address types with Schnorr signatures. Old nodes see Taproot outputs as anyone-can-spend (no requirement to verify the new signature scheme); new nodes enforce the Taproot rules.

Why soft forks are backward-compatible. The new rules are a strict subset of what was previously valid. Any block that satisfies the new rules also satisfies the old rules — old nodes see no anomaly. Non-upgraded nodes continue to participate; they just don’t enforce the new rules themselves.

The “anyone-can-spend” trick. Most soft-fork-introduced address types appear to old nodes as “anyone can spend this output.” New nodes enforce the new rules (e.g., “actually, this requires a Taproot Schnorr signature”). Old nodes accept whatever spending pattern new nodes produce because, from their perspective, anyone could have spent it. The protocol upgrade is invisible to old nodes; it’s effectively a new layer.

Backward-compatibility cost. Soft forks can never remove constraints — only add them. To loosen a constraint (e.g., increase the block weight limit), a hard fork would be required. This is the structural reason Bitcoin’s protocol can only become more restrictive over time via soft fork; functionality expansion happens via new opcodes or new validation paths added under tightening rules.

Hard forks: changing rules incompatibly

A hard fork changes the rules in a way that some new blocks become invalid under old rules. Non-upgraded nodes reject these blocks; new nodes accept them. The network splits into two chains.

Examples:

  • Hypothetical block-size increase to 8 MB. A block larger than 1 MB (4 MWU) would be invalid under current rules. New nodes accepting it; old nodes rejecting it. The chain splits.
  • Hypothetical change to issuance schedule. Modifying the subsidy curve to allow more BTC would create blocks old nodes reject.
  • Hypothetical change to the difficulty-adjustment formula. Replacing the 2016-block window with a per-block adjustment would change which blocks are valid.

Why hard forks require unanimous upgrade. If any subset of nodes refuses to upgrade, they continue enforcing old rules and reject new-chain blocks. They produce their own chain on the old rules; the network is split. Either side may be the “main” chain depending on hashrate distribution.

The Bitcoin Cash split (2017). When the dispute over block size couldn’t be resolved through soft fork mechanisms, a faction of users and miners forked Bitcoin to create Bitcoin Cash (BCH), with an 8 MB block size limit (later increased to 32 MB). Bitcoin proper (BTC) retained the 1 MB limit. The two chains have shared common ancestry through August 1, 2017, then diverged. Both still exist; BCH has substantially less hashrate and economic activity than BTC. See Bitcoin forks - History.

The empirical lesson: at Bitcoin’s scale, coordinated hard forks are essentially impossible. Coordination would require near-unanimous agreement among:

  • All major miners
  • All major exchanges
  • All major wallet providers
  • All major service providers
  • The Bitcoin Core development community

This level of coordination has never been achieved in Bitcoin’s history. The Bitcoin Cash split demonstrated that disputed hard forks just split the network; they don’t change protocol consensus.

Activation mechanisms

Soft forks need an activation mechanism — how the protocol knows when the new rules become enforced. Several have been used:

BIP-9 (versionbits) — used 2015-2017

  • The block header’s version field has 29 reserved bits available
  • Each pending soft fork is assigned a bit
  • Miners signal support by setting the bit in blocks they mine
  • If ≥95% of blocks in a 2016-block window signal support, the fork locks in for the next retarget
  • After one more 2016-block window, the fork activates — new rules become enforced
  • If the timeout expires (1 year by default) without 95% signaling, the fork fails

Used for: BIP-65 (CLTV), BIP-68/112 (CSV), BIP-141 (SegWit, with complications — see below).

Pros: miners explicitly signal readiness; activation is conservative. Cons: miners have veto power — if <5% oppose, the fork can stall.

BIP-148 (User Activated Soft Fork, UASF) — used during 2017 SegWit

The community-level response to miner foot-dragging on SegWit. BIP-148 (Shaolinfry et al., 2017) specified that as of August 1, 2017, nodes would reject any block that didn’t signal SegWit support — forcing miners’ hand. The mechanism shifts the activation locus from miners to economic users.

In practice, the threat of UASF activation contributed to the SegWit2x compromise (BIP-91), which lowered the BIP-9 threshold to 80% and activated SegWit before the UASF deadline. The 2x part of SegWit2x (a planned 2 MB block size increase) was canceled by the community before activation. Detailed chronicle in Block Size Wars - History.

UASF demonstrated that economic users (node operators, exchanges, wallet providers) have a backstop against miner-only veto. Miners derive revenue from the chain; if economic users reject their blocks, miners lose income. The threat is credible.

BIP-8 (with LOT=true / LOT=false) — proposed but not yet activated

BIP-8 (Shaolinfry, Luke-jr) is the modern UASF-friendly successor to BIP-9. Differences:

  • Replaces BIP-9’s “fail if timeout reached without 95%” with two variants:
    • LOT=true: at timeout, the fork activates anyway (UASF-style); blocks not signaling are rejected
    • LOT=false: at timeout, the fork fails (more conservative)

The LOT distinction was contested during the Taproot activation debate. The compromise was Speedy Trial (see below) — a shorter-window LOT=false variant that avoids the UASF backstop within the trial period.

Speedy Trial — used for Taproot 2021

A 3-month BIP-9-style activation window with LOT=false semantics. If miners signal sufficient support within the trial period, activation proceeds. If not, the fork fails — and a separate UASF would need to be organized to re-attempt.

Used successfully for Taproot in 2021: miners signaled overwhelmingly, the fork locked in within weeks, and activation happened in November 2021 without significant turbulence.

Speedy Trial demonstrated that uncontroversial soft forks can activate smoothly under the LOT=false model. Whether it works for contested soft forks is an open question.

Recent soft-fork history

SegWit (BIP-141, August 2017). Activated via BIP-9 versionbits with the BIP-91 reduced-threshold compromise after substantial political turbulence (the Block Size Wars). The activation locked in at ~80% miner signaling rather than the original 95%. Subsequent Bitcoin Cash split out as a separate chain via hard fork.

Taproot (BIP-341, November 2021). Activated via Speedy Trial. Minimal political contention; near-unanimous miner support; smooth activation. The contrast with SegWit’s activation is instructive — Taproot was technically narrower (changes opcode semantics in new address types; doesn’t affect existing UTXOs) and politically less contested.

No soft forks since 2021. Several are under discussion (OP_CAT re-enablement, BIP-300 Drivechains, post-quantum signatures) but none have entered formal activation. The post-Taproot quiet is the longest gap in Bitcoin’s recent protocol history.

For substantive engagement with current debates, see OP_CAT and the covenants programmability debate (Controversies) and BIP-300 and the Drivechains debate (Controversies). For why such changes are structurally difficult, see Protocol-evolution constraints (Criticisms).

The ossification question

A live cultural-political question: should Bitcoin’s protocol freeze entirely, or continue evolving?

The ossification camp argues:

  • The current rule-set is sufficient for Bitcoin’s primary use case (sound money / store of value)
  • Every protocol change introduces complexity and attack surface
  • Past changes (SegWit, Taproot) have brought meaningful improvements but the marginal benefit of further changes is small
  • Layer 2 (Lightning, sidechains) and off-chain construction can handle additional capabilities without base-layer changes

The continued-evolution camp argues:

  • Specific improvements (post-quantum migration, covenants for vaults, OP_CAT for various constructions) provide substantive value
  • Refusing all changes is itself a value choice that should be examined
  • Bitcoin’s cultural conservatism is appropriate but should not become absolute rigidity

The debate is genuinely contested. The post-2021 lull may indicate either “the ossification position is winning” or “the next round of changes is in pre-activation discussion.” The 2026 state is unclear.

Tradeoffs and design choices

Why soft forks dominate Bitcoin’s upgrade history. Three reinforcing reasons:

  1. Backward compatibility. Old nodes continue to participate; no forced upgrades; no chain splits from non-coordination.
  2. Lower coordination costs. Soft forks need miner support and node-operator acceptance, but not unanimous user upgrade.
  3. Cultural fit. Bitcoin’s culture is engineering-conservative; soft forks fit that disposition naturally.

The cost is that soft forks can only tighten rules. Functionality expansion happens via opcode additions, new address types, or new validation paths — all wrapped in tightening rather than loosening.

Why hard forks are politically near-impossible. At Bitcoin’s scale, no single party (no developer team, no miner pool, no exchange) can compel coordinated upgrade. Disputed hard forks just produce chain splits (as Bitcoin Cash demonstrated). Coordinated hard forks would require unanimity-of-interest across stakeholders that have substantively different incentives. The empirical record is unambiguous: 17 years, zero coordinated hard forks.

The “miner veto” problem. In BIP-9-style activation, miners can stall a soft fork by not signaling. This was exploited during SegWit activation (miners signaling delays for various reasons). UASF mechanisms (BIP-148, BIP-8 LOT=true) provide a structural backstop, but they’re contested in their own right — they shift activation power from miners to economic nodes, which some view as a different but equally problematic concentration.

The “Speedy Trial” precedent. Taproot’s Speedy Trial showed that uncontested soft forks can activate cleanly with short timelines and no UASF backstop. The model assumes the soft fork is uncontroversial enough that both miner support and economic-node acceptance will happen organically. For contested soft forks, the model is untested.

The Bitcoin Cash counterexample as ongoing lesson. Every subsequent protocol-evolution discussion happens in the shadow of Bitcoin Cash. Whenever someone proposes a contentious change, the implicit question is “are you proposing a fork that might split the chain like BCH did?” This is a powerful conservative force; it makes any but the most uncontroversial soft forks politically difficult.

For substantive engagement on the political-philosophical constraints around protocol changes, see Protocol-evolution constraints (Criticisms section). For the historical chronicle of the Block Size Wars dispute, see Block Size Wars - History (History section). For canonical book-length treatment, see The Blocksize War (book) - Jonathan Bier (source page).

Open questions for further development

  • Will any new soft fork activate in the foreseeable future? Post-Taproot quiet is now the longest in Bitcoin’s history; OP_CAT and related discussions are active but no activation is imminent.
  • If post-quantum signatures eventually require a protocol upgrade, will it be soft fork (most likely; adding new signature scheme alongside ECDSA/Schnorr) or hard fork (politically near-impossible)?
  • What’s the right level of cultural ossification? Stronger ossification means less flexibility; weaker ossification means more attack surface.
  • How will Speedy Trial’s precedent affect future activations? Is the model sufficient for contested soft forks, or is it specifically appropriate only for uncontested ones?

Canonical sources for this note

Bitcoin Improvement Proposals

  • BIP-9 — Versionbits soft-fork signaling.
  • BIP-8 — User-activated soft-fork signaling.
  • BIP-148 — Mandatory activation of SegWit deployment (UASF).
  • BIP-91 — Reduced threshold SegWit MASF.
  • BIP-141 — Segregated Witness consensus layer.
  • BIP-341 — Taproot.

Bitcoin engineering references

Historical and political

Graph View

Backlinks