11 Bitcoin upgrades

This chapter explains how Bitcoin’s rules can change and still preserve a single, shared ledger. It introduces the two kinds of consensus-rule changes—hard forks and soft forks—and emphasizes why safe rollout matters: the network is decentralized, each node chooses its own software, and upgrades must balance technical caution with broad social coordination. A recurring theme is that the “economic majority” of users ultimately defines Bitcoin’s rules by what software they run, while miners are paid to follow those rules, not set them.

Hard forks relax rules and risk permanent chain splits unless deliberately made incompatible with the old rules or protected with mechanisms like wipe-out protection; they also need replay protection so transactions do not unintentionally execute on both branches. Soft forks tighten rules so old nodes still accept new blocks, but if old miners produce blocks violating the tightened rules they can trigger temporary splits that later reorg away as adoption grows. The chapter uses examples such as increasing block size (hard fork), Segregated Witness (soft fork), the dangers of transaction replay, and why explicit replay and wipe-out protections may be needed when branches diverge.

Deployment mechanisms have evolved from ad hoc and miner-activated signaling toward more structured and user-empowering approaches. Early upgrades used coinbase text (BIP16) and then block-version thresholds (BIP34/66/65). Version bits (BIP9) enabled multiple parallel deployments with states like STARTED, LOCKED_IN, and ACTIVE, and worked smoothly for relative locktime (CSV) but stalled for SegWit, revealing that BIP9 grants a miner veto. SegWit ultimately activated via BIP91 and growing user pressure, highlighting that users drive consensus. The chapter concludes with user-activated soft forks (UASF) as a tool to align outcomes with the economic majority, and with hybrid designs that ensure upgrades proceed when broad user support exists even if some miners hesitate.

  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