How does a decentralized network upgrade itself when there's no central authority to mandate changes? Bitcoin has evolved significantly since 2009, adding new features while maintaining backward compatibility. This chapter examines the mechanisms that make this possible: the distinction between policy and consensus, the mechanics of soft forks, and the social and technical coordination required to upgrade a global monetary system.
16.1 Policy vs Consensus
Bitcoin nodes enforce two distinct sets of rules, and understanding their difference is crucial for reasoning about network upgrades.
Definition 16.1 (Consensus Rules)
Consensus rules determine block validity. A block violating any consensus rule is rejected and will never be accepted by the node, regardless of how much work is built on top of it.
Definition 16.2 (Policy Rules / Standardness)
Policy rules (also called standardness rules) determine which transactions a node will relay and accept into its mempool. Transactions violating policy are called "non-standard" but may still be valid if included in a block.
Example 16.1 (Standard vs Non-Standard)
| Transaction Type | Consensus | Standard Policy |
|---|---|---|
| P2PKH, P2WPKH, P2TR | ✓ Valid | ✓ Standard |
| OP_RETURN with 80 bytes | ✓ Valid | ✓ Standard |
| OP_RETURN with 100 bytes | ✓ Valid | ✗ Non-standard |
| Bare 15-of-15 multisig | ✓ Valid | ✗ Non-standard |
| Coinbase spending <100 conf | ✗ Invalid | N/A |
Remark 16.1 (Why Policy Exists)
Policy rules serve multiple purposes:
- DoS protection: Limit resource-intensive transactions
- Upgrade preparation: Make new features "standard" before mandatory
- Network hygiene: Discourage undesirable patterns
- Future flexibility: Reserve space for future soft forks
16.2 Hard Forks vs Soft Forks
Protocol changes are categorized by their compatibility properties.
Definition 16.3 (Hard Fork)
A hard fork relaxes consensus rules—it makes previously invalid blocks valid. Old nodes will reject blocks valid under new rules.
Definition 16.4 (Soft Fork)
A soft fork tightens consensus rules—it makes some previously valid blocks invalid. Old nodes will accept blocks valid under new rules (though they may not fully understand them).
Theorem 16.1 (Soft Fork Backward Compatibility)
If a soft fork activates with majority hash power support:
- Upgraded nodes enforce new stricter rules
- Non-upgraded nodes see a valid (if possibly confusing) chain
- The network remains unified on one chain
Proof sketch.
New rules are a subset of old rules. Any block valid under new rules is therefore valid under old rules. Old nodes accept the chain built by upgraded miners. Since upgraded miners have majority hash power, their chain will be longest/heaviest, and all nodes follow it. □
16.3 Activation Mechanisms
Soft forks require coordination to activate safely. Several mechanisms have been developed.
16.3.1 Flag Day Activation
Definition 16.5 (Flag Day)
A flag day activation enables new rules at a predetermined block height or time. Used in early soft forks (BIP-30, BIP-34).
16.3.2 BIP-9: Miner Signaling
Definition 16.6 (BIP-9 Version Bits)
BIP-9 allows miners to signal readiness for soft forks using version bits in block headers:
- Each soft fork uses one of 29 available bits
- Signaling occurs during a defined window
- Activation requires 95% of blocks signaling over 2016 blocks
- If threshold not reached by timeout, deployment fails
16.3.3 BIP-8: Mandatory Activation
Definition 16.7 (BIP-8)
BIP-8 extends BIP-9 with a lockinontimeout parameter.
If true, the soft fork activates at timeout regardless of miner signaling
(User Activated Soft Fork / UASF model).
16.3.4 Speedy Trial
Definition 16.8 (Speedy Trial)
Speedy Trial is a fast signaling period (typically 3 months) with a longer delay before activation. Used for Taproot (BIP-341).
16.4 Major Soft Forks in Bitcoin History
| Soft Fork | BIP(s) | Activated | Mechanism |
|---|---|---|---|
| BIP-34 (Height in Coinbase) | 34 | March 2013 | Miner voting |
| BIP-66 (Strict DER) | 66 | July 2015 | BIP-9 |
| BIP-65 (CHECKLOCKTIMEVERIFY) | 65 | December 2015 | BIP-9 |
| BIP-68/112/113 (Relative Locks) | 68, 112, 113 | July 2016 | BIP-9 |
| Segregated Witness | 141, 143, 144 | August 2017 | BIP-9 + UASF pressure |
| Taproot | 340, 341, 342 | November 2021 | Speedy Trial |
16.4.1 P2SH (BIP-16)
Remark 16.2 (P2SH Soft Fork)
Pay-to-Script-Hash (2012) made OP_HASH160 <hash> OP_EQUAL
outputs special. Old nodes see a simple hash check passing; new nodes
additionally execute the revealed script. This pattern—reinterpreting
previously "anyone can spend" outputs—became a template for future soft forks.
16.4.2 Segregated Witness (BIP-141)
Remark 16.3 (SegWit Soft Fork)
SegWit (2017) was the largest soft fork, adding:
- Witness data segregation (fixing transaction malleability)
- Block weight (effective capacity increase)
- Script versioning (enabling future upgrades)
- New address formats (bech32)
Old nodes see SegWit outputs as "anyone can spend" (but miners won't include invalid spends, so this is safe once majority hash power upgrades).
16.4.3 Taproot (BIP-341)
Remark 16.4 (Taproot Soft Fork)
Taproot (2021) added:
- Schnorr signatures (BIP-340)
- Taproot output type (BIP-341)
- Tapscript (BIP-342)
- Key aggregation capabilities (MuSig)
Taproot used witness version 1, leveraging SegWit's script versioning.
16.5 The Soft Fork Design Pattern
Most soft forks follow a common pattern: redefine outputs that old nodes see as valid (often "anyone can spend") to have new meaning.
Theorem 16.2 (Soft Fork Template)
A rule change is a valid soft fork if it can be expressed as:
- Identify a class of currently-valid transactions
- Add constraints that make some of them invalid
- Ensure the constraints are enforceable by upgraded nodes
16.6 Standardness as Soft Fork Preparation
Policy rules often prepare the ground for future consensus changes.
Definition 16.9 (Policy-First Deployment)
Policy-first deployment introduces new behavior in two stages:
- Make the new pattern "standard" (relayed, accepted in mempool)
- Later, make violations a consensus failure
Example 16.2 (SegWit Policy Evolution)
Before SegWit activated:
- Witness programs were made non-standard to spend improperly
- This prevented anyone from claiming "anyone can spend" outputs
- Once 95% of miners upgraded, consensus rules activated
- The policy protection was no longer necessary (consensus enforced)
Remark 16.5 (Standardness Changes)
Notable standardness changes that were not soft forks:
- OP_RETURN data size limits (policy only)
- Dust threshold (policy only)
- Replace-by-fee signaling (policy only)
- Mempool size limits (policy only)
These can be changed by individual nodes without network consensus.
16.7 Risks and Challenges
16.7.1 Chain Split Risk
Theorem 16.3 (Soft Fork Split Conditions)
A soft fork can cause a chain split if:
- Miners produce blocks violating new rules
- These blocks have enough work to be longest for old nodes
- Upgraded nodes reject them, following a shorter (but valid) chain
This is why 95% miner signaling is required—it ensures the new-rules chain will be longest.
16.7.2 Coordination Challenges
Remark 16.6 (Upgrade Coordination)
Soft fork deployment requires coordinating:
- Developers: Write and review code
- Node operators: Upgrade software
- Miners: Signal readiness
- Businesses: Test and integrate
- Users: Understand implications
This natural friction makes changes deliberate and conservative.
16.7.3 Irreversibility
Once a soft fork activates, reversing it would require a hard fork (the reverse operation). This makes soft forks effectively permanent.
16.8 Future Upgrade Paths
Bitcoin's design includes provisions for future upgrades.
16.8.1 Witness Versions
Definition 16.10 (Witness Versions)
SegWit defined 17 witness versions (0-16). Currently used:
- Version 0: P2WPKH, P2WSH
- Version 1: Taproot (P2TR)
- Versions 2-16: Reserved for future soft forks
16.8.2 Taproot's OP_SUCCESS
Definition 16.11 (OP_SUCCESS)
Tapscript redefines many unused opcodes as OP_SUCCESSx. These cause the script to immediately succeed, allowing future soft forks to give them new meaning without breaking existing scripts.
16.8.3 Proposed Soft Forks
Several soft forks are under discussion (as of 2024):
- OP_CTV (BIP-119): Covenants via CHECKTEMPLATEVERIFY
- OP_CAT: Re-enable concatenation opcode
- ANYPREVOUT (BIP-118): New sighash for Eltoo/LN-Symmetry
- Cross-input signature aggregation: Batch Schnorr verification
16.9 The Social Layer
Technical mechanisms are necessary but not sufficient for upgrades. The social layer—community consensus—ultimately determines what changes are accepted.
Remark 16.7 (Consensus Beyond Code)
"Consensus" in Bitcoin has two meanings:
- Technical consensus: Rules enforced by software
- Social consensus: Agreement among participants
Changes require both. Code without social consensus is an altcoin. Social consensus without code changes existing behavior.
Example 16.3 (SegWit Activation Controversy)
SegWit's activation (2017) illustrated social consensus dynamics:
- Technical readiness: 2015-2016
- Miner signaling stalled at ~30% for months
- User Activated Soft Fork (BIP-148) threatened August 1 activation
- Miners signaled rapidly, reaching 95% before the deadline
- Demonstrated that users, not just miners, determine consensus
Exercises
Exercise 16.1
Explain why "increasing the block size limit" would be a hard fork, while "decreasing the block size limit" would be a soft fork.
Exercise 16.2
A proposed change would make transactions with more than 100 inputs invalid. Is this a soft fork or hard fork? What might motivate such a change?
Exercise 16.3
Why does BIP-9 require 95% rather than 51% miner signaling? What could go wrong with a lower threshold?
Exercise 16.4
Research the "UASF" (User Activated Soft Fork) concept. How does it differ from miner-activated soft forks? What are its advantages and risks?
Exercise 16.5
If you wanted to add a new opcode (say, OP_SHA3 for SHA-3 hashing) to Bitcoin via soft fork, describe how you would design it using the OP_SUCCESS pattern in Tapscript.