Definition
Hard Fork is a change to Bitcoin’s consensus rules that is not backward-compatible: blocks or transactions that the new rules accept are rejected by nodes still running the old software. Any node that does not upgrade is left behind on a separate chain, so a hard fork can permanently split the network into two coins.
Also known as: a backward-incompatible consensus change, or a « chain-splitting » fork.
How a hard fork differs from a soft fork
Consensus rules are the shared rulebook every full node uses to decide whether a block is valid. A hard fork loosens those rules — it makes something previously invalid (a larger block, a new opcode, a different reward schedule) suddenly valid. Old nodes still enforcing the stricter original rules will reject the new blocks, so the two rule-sets cannot coexist on one chain. That is the opposite of a soft fork, which only tightens the rules so that upgraded and non-upgraded nodes keep following the same longest chain.
Bitcoin’s history leans heavily on soft forks precisely to avoid splits. SegWit (BIP141) and Taproot were activated as soft forks, signalled through bits in the block header version field. A hard fork, by contrast, demands that essentially everyone — nodes, wallets, exchanges, and miners — upgrade in lockstep, or the chain divides. The most famous example is the 2017 split that created Bitcoin Cash, which raised the block-size limit and removed SegWit, producing a chain that original Bitcoin nodes will never accept.
What actually splits: the role of consensus and mining
When a hard fork activates, both chains share an identical history up to the fork block. After that point, miners must choose which rule-set to extend. Their hashrate and proof-of-work flow to whichever chain they decide is worth securing, and each chain then runs its own independent difficulty adjustment to stabilise its own block time. A new chain that inherits only a fraction of the original network hashrate can see wild swings in block production until its difficulty re-anchors.
This is where decentralization does its quiet work. No central party can impose a hard fork; it succeeds only if a critical mass of independent operators voluntarily run the new code. A change that the broad base of node operators rejects simply withers — its chain attracts little hashrate and few users. Spreading that decision across thousands of sovereign participants is one more layer decentralized, and it is the reason Bitcoin’s core money rules (the 21-million cap, the block subsidy schedule) have proven so resistant to change.
Why an ASIC miner should care
For a home miner running an S19, a Whatsminer, or a Bitaxe, a hard fork is not an abstract governance debate — it decides which coin your machine is actually earning. Your hardware computes double-SHA-256 the same way regardless of the fork, but the chain you point it at determines the block reward currency, the mining pool you join, and the dollar value of every share you submit. The job templates your firmware receives over the Stratum protocol already encode the active consensus rules — for example, the coinbase and version fields a pool sends reflect whether SegWit is in force on that chain.
In practice, the choice is made for you by the pool and node software, not by your ASIC. As long as Bitcoin upgrades stay on the soft-fork path, your rig keeps following the same chain through every activation without a firmware change. If a contentious hard fork ever split the network again, you would decide which side to direct your hashrate to — and for most sovereign Bitcoiners that means staying on the chain the broadest set of independent nodes enforce, then verifying it with your own node rather than trusting a pool’s word for it.
If you are setting up a rig and want help choosing pools, hardware, and a firmware stack that puts you in control of where your hashrate points, the Bitaxe hub and D-Central’s miner catalogue are good starting points.
Related terms: Soft Fork, Fork, SegWit, Taproot, Longest Chain Rule, Difficulty Adjustment
In Simple Terms
A non-backward-compatible protocol change requiring all nodes to upgrade. Can permanently split the chain.
Hard Fork is a change to Bitcoin's consensus rules that is not backward-compatible: blocks or transactions that the new rules accept are rejected by nodes still running the old software. Any node that does not upgrade is left behind on a separate chain, so a hard fork can permanently split the network into two coins.
Also known as: a backward-incompatible consensus change, or a "chain-splitting" fork.
How a hard fork differs from a soft fork
Consensus rules are the shared rulebook every full node uses to decide whether a block is valid. A hard fork loosens those rules — it makes something previously invalid (a larger block, a new opcode, a different reward schedule) suddenly valid. Old nodes still enforcing the stricter original rules will reject the new blocks, so the two rule-sets cannot coexist on one chain. That is the opposite of a soft fork, which only tightens the rules so that upgraded and non-upgraded nodes keep following the same longest chain.
Bitcoin's history leans heavily on soft forks precisely to avoid splits. SegWit (BIP141) and Taproot were activated as soft forks, signalled through bits in the block header version field. A hard fork, by contrast, demands that essentially everyone — nodes, wallets, exchanges, and miners — upgrade in lockstep, or the chain divides. The most famous example is the 2017 split that created Bitcoin Cash, which raised the block-size limit and removed SegWit, producing a chain that original Bitcoin nodes will never accept.
What actually splits: the role of consensus and mining
When a hard fork activates, both chains share an identical history up to the fork block. After that point, miners must choose which rule-set to extend. Their hashrate and proof-of-work flow to whichever chain they decide is worth securing, and each chain then runs its own independent difficulty adjustment to stabilise its own block time. A new chain that inherits only a fraction of the original network hashrate can see wild swings in block production until its difficulty re-anchors.
This is where decentralization does its quiet work. No central party can impose a hard fork; it succeeds only if a critical mass of independent operators voluntarily run the new code. A change that the broad base of node operators rejects simply withers — its chain attracts little hashrate and few users. Spreading that decision across thousands of sovereign participants is one more layer decentralized, and it is the reason Bitcoin's core money rules (the 21-million cap, the block subsidy schedule) have proven so resistant to change.
Why an ASIC miner should care
For a home miner running an S19, a Whatsminer, or a Bitaxe, a hard fork is not an abstract governance debate — it decides which coin your machine is actually earning. Your hardware computes double-SHA-256 the same way regardless of the fork, but the chain you point it at determines the block reward currency, the mining pool you join, and the dollar value of every share you submit. The job templates your firmware receives over the Stratum protocol already encode the active consensus rules — for example, the coinbase and version fields a pool sends reflect whether SegWit is in force on that chain.
In practice, the choice is made for you by the pool and node software, not by your ASIC. As long as Bitcoin upgrades stay on the soft-fork path, your rig keeps following the same chain through every activation without a firmware change. If a contentious hard fork ever split the network again, you would decide which side to direct your hashrate to — and for most sovereign Bitcoiners that means staying on the chain the broadest set of independent nodes enforce, then verifying it with your own node rather than trusting a pool's word for it.
If you are setting up a rig and want help choosing pools, hardware, and a firmware stack that puts you in control of where your hashrate points, the Bitaxe hub and D-Central's miner catalogue are good starting points.
Related terms: Soft Fork, Fork, SegWit, Taproot, Longest Chain Rule, Difficulty Adjustment