Hard Fork

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 an upgraded-valid block can be legacy-invalid, old validators cannot simply keep following while preserving their rules.

Legacy full nodes do not know or accept the new validity condition. If upgraded miners produce a block that exceeds an old limit or uses a newly valid construction, old nodes stop at the last block they consider valid and reject the descendant chain regardless of its claimed upgrade status. They are not 'outvoted'; they are executing a different deterministic rule set.

A flag day, 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 with explicit split risk, not merely a threshold calculation.

At the fork point both branches inherit the same pre-fork UTXO history. Afterward they can confirm different transactions, enforce different limits and develop different cumulative work. If both survive, a holder at the fork generally has corresponding spendable claims on both chains, subject to each chain's later rules, replay protections and wallet support. The assets are no longer one ledger entry.

Proof of work resolves competing branches only among blocks a node already considers valid. A legacy node never compares chainwork of a branch containing a legacy-invalid block with its own valid branch; that candidate is discarded first. Upgraded nodes make the same decision under their own rules. 'The chain with most hash rate wins' is therefore incomplete without specifying the validation rules used before chainwork comparison.

A shared pre-fork transaction format can allow the same signed transaction to be valid on both chains, creating replay risk. Wallets and forks may add replay protection, new address encodings or different sighash rules, but these are separate design choices. Users must also avoid confusing identically derived addresses, balances and transaction IDs across networks and must understand exchange crediting and withdrawal policies.

Bitcoin Cash split from Bitcoin at block height 478,559 on 1 August 2017 after adopting rules that permitted larger blocks than legacy Bitcoin nodes accepted and removed SegWit-related assumptions from its chosen rule set. Bitcoin nodes rejected BCH-only blocks; BCH nodes followed their own valid chain. The event is a clean example of a planned hard fork becoming a persistent independent network rather than an in-place Bitcoin upgrade.

Not every incompatible split is an intentional monetary project. A software bug can make implementations disagree temporarily, and emergency releases can coordinate a return to one rule set. The March 2013 Bitcoin chain split, caused by database/lock-limit behavior differing between versions, was resolved by coordinated miner rollback to the chain accepted by older 0.7 nodes; it is historically important but unlike a deliberately sustained fork such as Bitcoin Cash.

A soft fork restricts validity so V(new) remains inside V(old); legacy nodes can follow compliant blocks but do not enforce the added restriction. A hard fork lacks that one-way compatibility: an upgraded-valid block may be old-invalid. Soft forks can still split if coordination fails, while hard forks require migration precisely because legacy validation rejects some intended new blocks by design.

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. A persistent hard fork exists when enough independent actors voluntarily maintain and value both rule sets. Naming one branch 'the upgrade' is social convention, not a validation primitive.

Operators should verify network identifiers, software release and consensus parameters, peer set, chain tip, block hash at the fork height and expected checkpoints or release notes. For significant funds, they should separate wallets and transaction workflows before spending forked coins. An explorer, exchange ticker or miner statement is useful evidence but cannot substitute for the rules enforced by the operator's own validating node.