TERM_DEF // FORKS_EXTENDED / CONTENTIOUS_HARD_FORK
CONTENTIOUS HARD
FORK
FORK
fork/">Contentious Hard Fork. A hard fork without economic consensus, creating two persistent chains and assets.
This page sits in the Forks (Extended) section — Less common but important kinds of forks beyond hard/soft. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
This page sits in the Forks (Extended) section — Less common but important kinds of forks beyond hard/soft. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
WHAT_CONTENTIOUS_HARD_FORK_IS
Contentious Hard Fork — at a glance
FORKS (EXTENDED)
Why it exists
DESIGN
Software evolves; bugs are found, new features are proposed. But Bitcoin has no CEO to push an update — every node operator decides what software to run, and only rules that get broad voluntary adoption end up enforced. The fork taxonomy (soft, hard, activation paths) is the vocabulary the community uses to describe how a change is proposed, validated, deployed, and either accepted or rejected.
HOW_IT_WORKS
Mechanism
HOW IT WORKS
**Soft fork**: a tightening of rules that's *backward-compatible* — old nodes still see new blocks as valid (just look unrecognised). SegWit and Taproot were soft forks. **Hard fork**: a relaxation or change that splits the chain — old nodes reject new blocks, so a hard fork requires every participant to upgrade or risk losing sync. BCH and BSV were hard forks. **Activation logic** (BIP-9 version bits, BIP-8 lock-in-on-timeout, Speedy Trial) coordinates the rollout.
1. A change is drafted (BIP) and circulated for review.
2. Reference implementation is built and merged into Bitcoin Core (or an alt client).
3. Activation parameters chosen — version-bit signal range, lock-in threshold, mandatory enforcement height.
4. Miners (and increasingly UASF — User-Activated Soft Forks) signal readiness in block headers.
5. Once threshold + lock-in is achieved, the new rule becomes mandatory at the activation height.
6. Non-upgraded nodes either accept the change implicitly (soft fork) or get split off (hard fork).
WORKED_EXAMPLE
Soft-fork history — every Bitcoin upgrade activated as a soft fork
EXAMPLE
BIP-30 (Mar 2012) — Duplicate-txid prevention (handled coinbase reorg edge case)
BIP-34 (Mar 2013) — Block height in coinbase (forced version bump to 2)
BIP-65 (Dec 2015) — OP_CHECKLOCKTIMEVERIFY (absolute timelocks in scripts)
BIP-66 (Jul 2015) — Strict DER signatures (closed signature-malleability holes)
BIP-112 (Jul 2016) — OP_CHECKSEQUENCEVERIFY (relative timelocks; enabled Lightning)
BIP-141 (Aug 2017) — SegWit (witness separation + weight metric)
BIP-340/341/342 (Nov 2021) — Taproot (Schnorr sigs + MAST + Tapscript)
Every one tightened rules and required no flag-day re-syncs.
Hard forks of Bitcoin (rejected by the longest-PoW chain):
Bitcoin Cash (2017) — increased block size, dropped SegWit
Bitcoin SV (2018) — further BCH fork, even larger blocks
Bitcoin Gold (2017) — changed PoW algorithm
None are "Bitcoin" — they are separate chains with separate tickers.
KEY_PROPERTIES
BACKWARD-COMPATIBLE
Soft forks add restrictions only. Old software keeps validating; new outputs just look unrecognised, not invalid.
BREAKING
Hard forks relax or change consensus rules; old software rejects new blocks, so adoption must be unanimous to avoid a chain split.
OPT-IN
Every node operator chooses which software to run. A fork only "happens" to a participant if they upgrade to it.
COORDINATED
Activation parameters are set in code months ahead of deployment; the network signals readiness via version bits.
COMMON_PITFALLS
Things that catch people out
PITFALLS
- "Hard fork" and "altcoin" are nearly synonymous in practice — the rejected chain becomes a separate currency, not "Bitcoin".
- A soft fork without miner support can still activate via UASF (BIP-148 was the famous example for SegWit lock-in).
- Don't confuse a "fork" (a consensus rule change) with a "code fork" (a github fork of the source). Different concepts.
RELATED_CONCEPTS
Other terms from Forks (Extended) — click any to read its page:
TERMINOLOGY_INDEX
TERMINOLOGY
Contentious Hard Fork
A hard fork without economic consensus, creating two persistent chains and assets.
Software Fork (Alternative Client)
A different codebase implementing the same consensus rules; useful for client diversity.
Mining Fork (Miner-Driven Divergence)
A temporary divergence caused by two miners finding blocks at the same height.
Network Fork (Node Partition)
A split caused by network partitioning; resolves when connectivity returns.
Spontaneous Fork (Propagation Race)
Routine, short-lived fork happening when two valid blocks race to propagate.
Buried Deployment (BIP 90)
Once a soft fork is deep enough in the chain, its activation logic is removed in favour of an unconditional rule.