Home › Glossary › Hard fork

Hard fork

Also called: hardfork, hard-fork, chain split, backward-incompatible upgrade.

A hard fork is a change to Bitcoin's consensus rules that makes previously invalid blocks valid, so nodes that don't upgrade split off the chain.

A hard fork loosens Bitcoin's consensus rules: blocks or transactions that old software rejects become valid. Nodes that don't upgrade reject the first block that uses the new freedom and keep following a chain without it, so a hard fork without near-universal adoption splits the network in two. BIP 99 defines it as a consensus fork "that makes previously invalid blocks valid" and notes that hard forks "require all users to upgrade".

Hard forks and the block size debate

Raising the 1,000,000-byte block size limit was the most discussed hard fork. Several BIPs described how it could be done: BIP 101 (8 MB, doubling every two years), BIP 102 and BIP 109 (one-time increases to 2 MB), and growth schedules or dynamic limits in BIP 100, BIP 103, BIP 104, BIP 105, BIP 106 and BIP 107. Bitcoin adopted none of them. Capacity was instead raised by SegWit's block weight rule, a soft fork. Projects that changed the block size by hard fork, such as Bitcoin Cash in 2017, became separate networks with their own coins.

Has Bitcoin ever had a hard fork?

Bitcoin has never activated a planned hard fork. The closest event is described in BIP 50, Gavin Andresen's post-mortem of March 2013. A block that Bitcoin 0.8 accepted was rejected by older versions because of an undocumented database lock limit, and the chain split. Mining pools downgraded to restore a single chain, and version 0.8.1 temporarily limited blocks so older nodes could keep up. BIP 50 records that on 16 August 2013 block 252,451 was accepted by the main network, forking unpatched nodes off it.

Every consensus change Bitcoin has deployed since has been a soft fork; the soft forks guide explains why.

BIPs that define Hard fork

  • BIP 99: Motivation and deployment of consensus rule changes ([soft/hard]forks): Closed. Lays out a classification of the different ways Bitcoin's core rules can be changed, such as soft forks and hard forks, and explains the reasons behind each. It also recommends how each type should…
  • BIP 50: March 2013 Chain Fork Post-Mortem: Deployed. A post-mortem of the March 2013 incident in which a database limit in older Bitcoin software caused the blockchain to split temporarily. It explains what went wrong, how miners and developers…
  • BIP 101: Increase maximum block size: Closed. Proposed replacing the fixed 1 MB block size limit with a limit that grows automatically on a predictable schedule over time. Supporters argued it would let Bitcoin handle more transactions as…
  • BIP 102: Block size increase to 2MB: Closed. Proposed a single, simple increase in the maximum block size from 1 MB to 2 MB to allow more transactions per block. Being a change that older software would reject, it would have required a hard…
  • BIP 109: Two million byte size limit with sigop and sighash limits: Closed. Proposed doubling the block size limit from 1 MB to 2 MB, alongside new caps on signature checks and data hashing to stop specially crafted blocks from overloading nodes. It was associated with the…
  • BIP 100: Dynamic maximum block size by miner vote: Closed. Proposed replacing Bitcoin's fixed 1 MB block size limit with one that miners could vote to raise or lower, with votes counted on the same two-week cycle as mining difficulty adjustments. It was one…
  • BIP 103: Block size following technological growth: Closed. Proposed gradually increasing the block size limit at a rate meant to track improvements in hardware and internet bandwidth. The goal was to allow more transactions while keeping it practical for…
  • BIP 104: 'Block75' - Max block size like difficulty: Closed. Proposed 'Block75', which would adjust the maximum block size every two weeks so that blocks stay about 75 percent full on average. Like the difficulty adjustment, it reacts to recent activity,…
  • BIP 105: Consensus based block size retargeting algorithm: Closed. Proposed a mechanism for changing the maximum block size based on votes or consensus among network participants rather than a fixed number. It aimed to let the limit adapt over time without repeated…
  • BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap: Closed. Proposed letting the maximum block size rise or fall at each difficulty adjustment based on how full recent blocks were, with a variant that also considered miners' fee income. The idea was to adapt…
  • BIP 107: Dynamic limit on the block size: Closed. Proposed a block size limit that adjusts automatically according to the volume of transactions on the network. The aim was to expand capacity when demand is high while avoiding a fixed number that…

Related terms

  • Soft fork: A soft fork is a backward-compatible change to Bitcoin's consensus rules that only tightens them, so old nodes still accept the new blocks.
  • Consensus rules: Consensus rules are the checks every full node applies to decide whether a block or transaction is valid; a block that breaks one is rejected.
  • Block weight: Block weight is the SegWit-era measure of block size: non-witness bytes count 4 units and witness bytes 1, with a limit of 4,000,000 weight units.

Learn more

Guides