11 Bitcoin upgrades

Bitcoin upgrades revolve around changing the network’s consensus rules, which this chapter frames as “forks.” Because each node is sovereign and users choose the software they run, coordinating changes is delicate: differing rules across nodes can cause temporary or lasting chain splits. The chapter establishes the core mental model—what counts as consensus vs. non-consensus changes, how nodes validate blocks, and why safe rollout matters—then centers the guiding principle that the economic majority of users ultimately determines the rules while miners are incentivized to follow them.

Two fork types define upgrade dynamics. A hard fork relaxes rules so New blocks may be invalid to Old nodes; without deliberate incompatibility (“wipe-out protection”), the New branch risks being reorganized away if Old regains hash rate. A soft fork tightens rules so New blocks remain valid to Old nodes, but Old can still produce blocks invalid to New; in a split, the Old branch risks wipe-out as adoption grows. Chain splits create two spendable UTXO sets and expose users to transaction replay, which replay protection (for example, altered signature hashing rules) prevents by making transactions valid on only one branch.

Deployments have evolved to minimize split risk. Early miner-activated soft forks used coinbase text signaling (BIP16), then block-version thresholds (BIP34/66/65), and later version-bits (BIP9) with staged states (DEFINED → STARTED → LOCKED_IN → ACTIVE, or FAILED). This enabled parallel proposals (e.g., CSV) but also revealed a drawback: BIP9 effectively grants small miner minorities a veto, as seen in SegWit’s stalled signaling until BIP91 coordination nudged activation. The experience revitalized user-activated soft forks (UASF), which put enforcement in users’ hands and, in emerging hybrid approaches, guarantee activation after a deadline if miners do not cooperate. The overarching lesson is to upgrade cautiously, prefer designs that avoid prolonged splits, and respect that users—through the software they choose—collectively set Bitcoin’s rules.

  Your new message will be accepted by Bitcoin New and ignored by Bitcoin Old.

  Qi gets a transaction twice. First during transaction propagation, second during block propagation.

  Compact blocks in action. Rashid sends just the necessary data to Qi.

  Your node running Bitcoin New is a loser against the Bitcoin Old nodes. Bitcoin Old will discard all your blocks that violate the ≤ 4,000,000 WU rule.

  A majority of the hash rate runs Bitcoin New. It seems to have caused a permanent chain split.

  The New chain is wiped out because the Old chain becomes stronger.

  Bitcoin Cash protects against wipe-out by requiring the first block after the chain split to be >1MB.

  An Old miner regards a segwit output as anyone can spend and adds a transaction that spends it as such to the block.

  The soft fork may cause a chain split if the Old nodes produce a block that New miners don’t accept.

  As people adopt Bitcoin New, your branch will cause a reorg for Bitcoin Old nodes.

  After a chain split you effectively have two versions of your UTXOs.

  Your transaction to the book store is valid on both the Old branch and the New branch.

  Transaction replay causes you to pay in both currencies

  With replay protection, a transaction is only valid on one of the branches.

16. A miner signals support for pay-to-script-hash by writing "/P2SH/" in the coinbase’s signature script.

17  The block header contains a block version. The first blocks used version 1.

  BIP34 requires that all blocks contain the block height in the coinbase.

   Miners that run the soft fork signal support for it by increasing their block version.

  The Old nodes could cause a chain split, but it probably won’t last for long.

  The block version is treated differently. Each of the right 29 bits can signal for different proposals.

  State transitions happens every 2016 blocks.

  BIP9 deployment of csv. It went well.

  The segwit deployment didn’t proceed as anticipated.

  BIP91 updates its state every 336 blocks instead of the usual 2016. This went fast.

  Segwit finally activates thanks to BIP91.

   Users start rejecting big blocks. They see no new valid blocks, but plenty invalid (too big) blocks.

  One miner decides to go with the users' will and only build small blocks. That miner will be able to pay the bills.

  A few more miners realize that it’s more profitable to work on the users' branch.

  The users' branch is stronger and wipes out the big blocks branch.

 Hard and soft forks compared.

  . BIP9 states

   User-activated soft fork states

  Some blocks are only valid on Old nodes and some blocks are only valid on New nodes.

• We don’t want a blockchain split when deploying a fork, because that would cause disruption in the Bitcoin economy.
• A hard fork is a consensus rule change that requires every miner to upgrade. Otherwise the blockchain will split.
• A soft fork is a consensus rule change that doesn’t require simultaneous upgrade of the whole network.
• A hard fork will lead to a blockchain split if a majority runs the New software, which will cause confusion among users and miners.
• During a blockchain split due to a hard fork you want wipe-out protection to make sure the New branch isn’t deleted by old nodes.
• In a blockchain split, you want replay protection to let you select what branch you want your transactions applied to.
• A miner-activated soft fork, for example one using BIP9 for deployment, lets miners deploy a non-controversial soft fork.
• A user-activated soft fork lets users enforce deployment of a soft fork. If a hash-rate majority eventually follows, the soft fork succeeds without a lasting blockchain split.

FAQ