Security & Resilience
Sharp hashrate declines
Protocol referenceSource: Bitcoin Developer Guide, Block ChainDescribes the difficulty adjustment and the target block interval; the decline scenario is an application of those rules.
What causes a sudden decline
Hash power leaves the network when mining becomes unprofitable at the prevailing price and cost of energy, when a large operator suffers an outage or a regulatory interruption, or when hardware is redeployed elsewhere. The decline can be gradual or abrupt. What matters for the protocol is not the cause but the size and speed of the change: the difficulty target is set for the hash power the network had at the last retarget, and if the actual hash power falls below that, blocks are found more slowly than the target interval.
The difficulty adjustment is the mechanism that responds. Every 2,016 blocks the network compares the time it actually took to produce those blocks with the time the target interval implies, and adjusts the difficulty up or down in proportion. The adjustment is bounded, so a very large change in hash power is corrected over several retarget periods rather than in one. This is deliberate: the bound prevents a single anomalous period from moving the difficulty so far that it destabilises the network.
Block times and the retarget lag
If half the hash power leaves, the remaining miners find blocks at roughly half the rate, and the average interval between blocks stretches toward twenty minutes until the difficulty falls. The network does not stop, because the remaining miners are still producing valid blocks and the difficulty is still achievable for them. What changes is the pace. A transaction that would have confirmed in ten minutes may take considerably longer, and the variance around that average is wide, because block discovery is a random process rather than a metronome.
The lag is the important part. The difficulty only changes at a retarget boundary, and a retarget boundary is defined by block height rather than by time. If blocks are being found slowly, the boundary itself arrives slowly, so the period during which the difficulty is too high lasts longer than it would if blocks were arriving on schedule. A large decline can therefore produce a stretch of slow blocks that persists for several retarget periods before the difficulty has fallen far enough to restore the target interval.
The difficulty adjustment page covers the retarget arithmetic, and the hashrate page describes how the network's total hash power is estimated from the blocks themselves.
Confirmation confidence during a decline
Confirmation estimates are built on the assumption that the honest network controls a large majority of hash power and that blocks arrive at roughly the target interval. A sharp decline weakens both assumptions for a period. The honest network's share of hash power falls in absolute terms, which raises the fraction an attacker would need to control, and the interval between blocks becomes longer and more variable, which changes the time a given number of confirmations represents.
The practical effect is that a confirmation count that was comfortable before the decline may be less comfortable during it, not because the rules have changed but because the hash power backing the chain has fallen. A merchant or an exchange that wants to keep the same level of assurance through a period of declining hash power may choose to wait for more confirmations, or to wait for the difficulty to adjust and the interval to return toward normal. This is the same judgement described on the double spending page, applied to a period in which the network's hash power is unusually low.
The decline is self-correcting in the sense that the difficulty adjustment restores the target interval, and the network's hash power typically recovers as mining becomes profitable again at the lower difficulty. It is not self-correcting in the sense of restoring the previous level of hash power; that depends on the economics of mining, which the protocol does not control. The security budget described on the security budget page is what determines whether it does.
Sources
- Bitcoin Developer Guide, Block Chain — the difficulty adjustment and the target block interval.
- Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System — section 4 describes the proof-of-work chain and the difficulty target.
- Bitcoin Core, proof-of-work implementation — the retarget calculation and its bounds.
Related reading
- Security & ResilienceHow the network resists attack, and what happens when it is stressed.
- Can Miners Cheat?What a miner can and cannot do with the block it finds, and why invalid blocks fail.
- Double SpendingHow a double spend works, and why confirmation depth is the defence.
- 51% AttacksWhat a majority of hash rate can achieve, and what it cannot.
- Eclipse AttacksHow a node can be isolated from the honest network, and the defences against it.
- When Your Node Goes OfflineWhy a disconnected node is not a threat, and how it catches up on return.