Hard fork

A hard fork is a change to the rules that old software does not accept. Blocks made under the new rules are invalid to old nodes, so the chain splits into two chains that follow different rules. Unless every node upgrades, both chains can keep going.

How is a hard fork different from a soft fork?

A soft fork makes the rules stricter, so old nodes still accept the new blocks. A hard fork does the opposite. It makes valid some blocks that the old rules reject, such as larger blocks or a new block structure. Old nodes cannot follow the new chain, so they stay on the old one.

How does a hard fork split the chain?

Suppose a new version of the software accepts blocks larger than the current 4,000,000 weight-unit limit. Miners who upgrade start building blocks of the new size. The split happens when the first oversized block is mined. Old nodes reject it, and new nodes reject the smaller blocks the old miners keep building.

From then on there are two chains, and each one grows as long as miners extend it. If the old side keeps more hash power, the new side can die out. If the new side keeps growing, two chains remain.

What kinds of change cause a split?

A change to any consensus rule that every node enforces can lead to one. Three kinds of change do this:

• Block structure: a higher block size limit, for example.
• Transaction structure: a new signature scheme that old transactions would not satisfy.
• Other consensus rules: raising the maximum supply, or manually changing the target to make blocks easier to mine.

Not every upgrade needs one. Changes that alter the core rules at the base of the system can only come this way.

When is a hard fork the only option?

If a change cannot be expressed as a soft fork, a hard fork is the only option. Even when a soft fork is possible, a hard fork can be the simpler route, because the new code does not have to fit inside the old rules.

Why are hard forks risky?

A hard fork has two main problems.

• Everyone has to upgrade. A node on old software stops receiving the new blocks, so it falls behind. Its owner keeps the coins but cannot see or send new payments on the new chain. Forcing an upgrade on every node is a harsh way to change a network that has no owner.
• A disagreement divides the network. If some miners upgrade and others do not, the chain splits into two histories. Hash power splits too, so each chain is easier to attack with a 51% attack. Users must also decide which chain's coins they trust. Merchants face the same question, and the confusion can damage trust in the currency.

Old miners can also undo a hard fork by building the longest chain of old blocks. The upgrade only sticks if the new chain can outgrow that one.

What would justify a hard fork?

Small fixes are not worth the risk. For example, the OP_CHECKMULTISIG opcode takes one extra item off the stack, and the rule cannot be fixed without a fork. The block header's nonce is also too small, so miners must change the coinbase to keep searching. And the block hash is shown in reverse byte order in explorers but stored in natural byte order inside raw data. Each of these is a real wart, but fixing it would mean every node upgrades.

Hard forks are reserved for urgent problems. Two examples are a serious weakness in the SHA-256 hash function, and a loss of so much hash power that blocks slow to a crawl. In that second case, the target would have to be raised by hand, because the normal adjustment changes it only once every 2,016 blocks.

What hard forks have happened?

Bitcoin Core developers have not proposed an intentional hard fork to the bitcoin chain. The events below happened by accident, or in a copy of the chain.

The 2013 database change

Bitcoin versions before 0.8 used Berkeley DB. It had a lock limit, and a large block with many inputs needed more locks than it allowed. That limit had become an unwritten rule. Version 0.8 switched to LevelDB, which had no such limit, and it accepted that block. Nodes on 0.7 rejected it, so the chain split.

Most of the mining power was on the 0.8 chain. Miners that ran 0.8 downgraded to 0.7 to restore one chain, and the 0.8 nodes reorganized back. Developers then released version 0.8.1 with new rules, and on 16 August 2013 block 252,451 made the change permanent. Unpatched nodes were forked off the network. BIP 50 is the post-mortem.

The 2017 Bitcoin Cash split

In 2017, some people in the bitcoin community wanted bigger blocks, and they opposed the SegWit upgrade under debate. They proposed a hard fork that raised the block size limit to 8 MB. That proposal became Bitcoin Cash.

The fork took effect on 1 August 2017. Both chains were identical up to block 478,558. The first block under the new rules was block 478,559, and it started the Bitcoin Cash chain. Coins held before the split existed on both chains, so holders could then control coins on each one.

Bitcoin Cash split again in November 2018, when a group created Bitcoin SV. It split a second time in November 2020, when a group created what is now called eCash. Those are separate hard forks, and this page covers them only as history.

A crash bug in 2018

Versions 0.14.0 up to 0.16.2 had a bug, CVE-2018-17144, that a miner could trigger. A block containing a transaction with a duplicate input could crash some nodes. That was a denial-of-service problem, not a chain split. It was fixed in version 0.16.3, and no hard fork took place.

Summary

A hard fork is a change that old nodes reject, so the chain splits into two. Everyone must upgrade for the network to stay on one chain, and a split divides both the coins and the hash power. Bitcoin Cash began this way in 2017, at block 478,559. Bitcoin itself has had no intentional hard fork, and the changes it has made came as soft forks.