42 / 736FORK↑

Hard Fork

A rule change that old software may reject

A Hard Fork permits something Bitcoin's old rules prohibited. A new node may therefore accept a block that an old node rejects. If both groups continue independently, their payment histories diverge too; two lasting currencies do not appear automatically.

A Hard Fork changes block or transaction validity rules in a way that is not backward compatible with older nodes. To follow the new incompatible chain, a node must adopt the new rules. Announcing the change or directing more mining power to it cannot force that choice.

Anna and Pavel each run a Full Node, a computer that independently checks Bitcoin's rules. Anna installs new software allowing larger blocks; Pavel keeps the original limit. A block arrives that satisfies the new conditions but exceeds the old limit. Anna accepts it; Pavel rejects it. This is not a broken connection: their programs disagree about what belongs in the shared history. That is the practical meaning of a Hard Fork. Calling it an upgrade does not persuade Pavel's computer to ignore its own rule. Two branches can continue if someone produces blocks for each and people use them. If participants move to one rule set, two living networks need not remain. [1]

An old node rejects the incompatible block and the branch built on it. That does not mean it gets stuck forever. If miners continue another branch under the original rules, it can keep accepting those blocks. Without such a continuation, it stays at the last block it considers valid. What matters is its software's rules, not how many people support the change: it is not 'outvoted'. To follow the incompatible branch, the operator must deliberately change those rules. [1]

Bitcoin Cash split from Bitcoin at block height 478559 on 1 August 2017. It adopted rules allowing larger blocks than Bitcoin nodes accepted at the time and created its own continuing chain. Bitcoin nodes rejected BCH-only blocks, while BCH nodes followed their own valid history. This is a Hard Fork that created a separate network rather than replacing Bitcoin through an upgrade within the existing network. [3] [4]

Think of the wallet’s record of funds received and not yet spent: Bitcoin calls such an unspent transaction output a UTXO. Branches with a shared past inherit that record, then manage it independently. If you control the necessary keys and both networks still recognize the output, you can usually spend the corresponding coins on both. This does not double their value: they are different assets with their own demand. For funds held on an exchange, receiving coins on the other network also depends on that exchange's crediting policy. [4] [6]

If you have coins on both branches, you may want to pay on just one. Without protection, someone could copy the signed transaction and broadcast it on the other, where it might also be valid. This is replay risk. Check the specific network's protection and the wallet's support. For example, changing sighash—the rules for what data a signature covers—can bind a transaction to a particular chain. A different address appearance helps distinguish networks but does not itself provide cryptographic replay protection. [3]

Activation is the designated point at which the new rules begin to apply. Block height identifies a block's position in the chain. A scheduled date, block height or miner signal can coordinate upgraded participants, but it cannot rewrite software on nodes that did not adopt the change. If meaningful economic actors remain on both rule sets, both chains can continue. A hard-fork activation plan is therefore a migration plan that must account for the risk of a split. [1]

Governance here means how participants make decisions about changes. A ticker is an asset's trading symbol, such as BTC or BCH. Developers can publish code, miners can allocate hash rate, businesses can choose tickers and deposit policies, and users can choose software. None of those actions automatically modifies another participant's consensus rules: the rules their node uses to check blocks. A persistent split can continue when enough independent participants voluntarily maintain and value both rule sets; not every incompatible rule change must create two permanently active networks. Naming one branch 'the upgrade' is social convention, not a rule that nodes enforce. [1]

A network can split without anyone intending to create a new currency. In the March 2013 Bitcoin chain split, some older nodes could not process a block with an unusually large number of transaction inputs. They hit a limit on database locks, which prevent concurrent operations from changing the same data. The newer 0.8 version used a different database and accepted the block. The BTC Guild and Slush mining pools returned to version 0.7 and mined on the branch that older nodes could also accept. Once that branch accumulated more work, the newer nodes switched to it too. This repaired an unintended software disagreement; it was not an attempt to maintain a separate network like Bitcoin Cash. [2]

A soft fork restricts validity by tightening the existing rules. A block that meets the new restrictions therefore also meets the old rules. An older node can accept it without checking the added restrictions itself. A Hard Fork lacks this compatibility: a block accepted by the new software may break the old rules. To accept it, the operator of an older node must change the rules its software enforces. A Soft Fork does not guarantee that the network will stay together either: if miners produce a block that breaks a new restriction, older and newer nodes may reach different decisions. [1]

Let V(old) denote every block accepted by the legacy consensus rules. A hard fork occurs when upgraded software accepts at least one block outside V(old), so V(new) is not a subset of V(old). Many hard forks expand validity, but the decisive test is compatibility: if a block accepted by a newer node can be rejected by an older one, the older node cannot keep following that chain without changing its rules. [1]

Chainwork measures the cumulative work demonstrated by mining the blocks of an entire branch. Hashrate, by contrast, is the rate of mining computation. A node chooses the branch with the most cumulative work only from chains that satisfy its rules. If a block breaks those rules, more work cannot make it acceptable. Pavel, in the opening example, will therefore not accept an oversized block just because most miners are building on it. Proof of Work can settle competition between valid branches; it cannot choose the rules on behalf of the node operator. [1]

Start by checking the network, supported wallet and replay protection. A familiar coin name or similar address is not enough. Do not enter your Seed Phrase, the wallet's recovery words, into an unknown service promising to claim forked coins. If you run your own node, you can also check its software version, connected nodes, latest accepted block and the fingerprint of the block at the split. That fingerprint is called a hash. Compare those details with the network's documentation; a block explorer's display does not replace checking the rules yourself. [5] [6]

For the clearest picture, read this entry together with Soft Fork, Consensus Rules, Full Node, Reorg, Blocksize War, UTXO. The reverse links also lead from Soft Fork, BIP (Bitcoin Improvement Proposal), Reorg, Blocksize War.

DOC · 001Bitcoin Developer Guide — Consensus rule changesDocumentation DOC · 002BIP 50 — March 2013 chain fork post-mortemSpecification DOC · 003Bitcoin Cash upgrade specification — 2017 hard forkSpecification DOC · 004BCHN Technical Bulletin — shared history and 2017 splitPrimary DOC · 005Bitcoin Core v29.0: getblockchaininfoDocumentation DOC · 006Bitcoin.org — Securing your walletDocumentation
Revised: Source-first · No investment advice