Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Security & Resilience

Network partitions

A partition is what happens when two groups of nodes can no longer hear each other. Each group continues to mine and validate, and for as long as the split lasts there are two chains where the network normally has one. When connectivity returns, the most-work rule picks a winner and the losing chain's transactions return to the mempool. The protocol has no separate partition-recovery procedure because chain selection already is one.

Protocol referenceSource: Bitcoin Developer Guide, Block ChainDescribes the most-work chain rule that resolves competing tips; the partition scenario is an application of it.

Two chains, one network

A partition is a failure of connectivity rather than a failure of consensus. A submarine cable is cut, a country's international links are disrupted, a large hosting provider loses its network, or a firewall blocks the ports Bitcoin uses. Nodes on each side of the split continue to run. They keep validating, they keep mining, and they keep extending the chain tip they can see. Because neither side can hear the other, each side's tip advances independently, and the network temporarily has two chains that share a common ancestor but diverge after it.

Both chains are valid. Every block on each side satisfies the consensus rules, and every node on that side has correctly validated it. There is no rule that says a block is invalid because some other node has not seen it. The protocol does not attempt to prevent the split, because preventing it would require a node to stop accepting valid blocks when it loses contact with its peers, which would make the network fragile in exactly the situation where it needs to keep working.

The practical consequence during the split is that a transaction confirmed on one side is not confirmed on the other. A merchant on one side of the partition may see a payment that a merchant on the other side does not. This is the same confirmation question as the double spending page, but the cause is a network fault rather than an attacker.

How accumulated work reunifies them

When connectivity returns, nodes on each side begin to receive blocks from the other. Each node compares the total accumulated proof of work of the two chains and follows the one with more. The comparison is not by block count but by work: a chain with fewer blocks but higher difficulty can carry more work than a longer chain at lower difficulty, and Bitcoin Core tracks the cumulative value internally as a 256-bit integer. The chain with less work becomes stale, and the nodes that were following it reorganise onto the winning chain.

A reorganisation is not a loss of data. Transactions that were in blocks on the losing chain and are still valid return to the mempool, where they can be included in a later block on the winning chain. Transactions that conflict with the winning chain — because they spend an output that the winning chain has already spent differently — are dropped. A transaction that was confirmed only on the losing side is therefore unconfirmed again, and a recipient who acted on it has to wait for it to be re-mined.

The depth of the reorganisation is bounded by how much work each side accumulated during the split. A short partition produces a shallow reorganisation of a few blocks. A long partition, or one in which one side has a large share of hash power, can produce a deeper one. This is why the duration of a partition matters: the longer the two sides diverge, the more work the losing side has to give up.

Why no separate recovery procedure is needed

A partition is a fork at a larger scale, and the rule that resolves a fork is the rule that resolves a partition. There is no partition-detection protocol, no vote among nodes, and no administrative step. Each node independently applies the most-work rule to whatever chains it can see, and because every node applies the same rule to the same set of blocks, they converge on the same answer once they can see the same blocks. The convergence is a consequence of the rule, not of any coordination.

The design does have a cost. During a partition, the two sides duplicate work, and the side that eventually loses has spent hash power on blocks that will be discarded. The protocol accepts that cost because the alternative — halting when connectivity is lost — would make the network dependent on continuous global connectivity. The 51% attacks page describes what happens when one side of a split has a deliberate majority rather than an accidental one.

Sources

Related reading