46 / 736STALE

Stale Block

A valid block left outside the main chain

A Stale Block is a valid Bitcoin block left on a side branch. No fraud is required: two miners can find blocks almost simultaneously, and the network later continues along just one of those branches.

A Stale Block follows Bitcoin's rules but is not part of the active chain. That is the history a node uses to count confirmations and determine which funds can be spent. A node is a computer that checks blocks and transactions. Accumulated mining work determines which valid branch it follows. For someone receiving a payment, this may mean losing a confirmation and waiting again, rather than automatically losing bitcoin.

Imagine two miners, Anna and Pavel. Both are working on a successor to the same latest block. Anna finds a new block, but before the news reaches Pavel, he finds one too. Both blocks can be valid, with slightly different sets of transactions. The nodes checking blocks and transactions hear about them in different orders. For a while, they therefore follow different ends of the chain. Once one valid branch has accumulated more work and nodes have verified it, they switch to that branch. A block left on the abandoned branch is called a Stale Block. [1]

Bitcoin needs a single history so that the same funds cannot be successfully spent twice. Checking that each competing block follows the rules is therefore not enough. A node must also choose which valid branch to follow. These are separate questions: block validity and chain selection. A Stale Block can have a valid Proof of Work, the evidence of mining work, valid transactions and valid signatures, yet still be outside the chosen history. That does not make it defective or fraudulent. [1] [2]

Suppose Pavel's block included your payment and your wallet showed one confirmation. If Anna's branch eventually wins, what happens depends on its contents. The same transaction may be there too, in which case it remains confirmed. Otherwise, it may return to the Mempool, a node's local list of unconfirmed transactions, and wait for another block. Returning is not guaranteed: the transaction must still be acceptable and must not conflict with the new history. If that history already contains a different transaction spending the same funds, the original payment cannot also be confirmed in it. [2]

An ordinary payment differs from the Coinbase Transaction, the first transaction in a block, which credits the miner's reward. That reward includes newly issued bitcoin and transaction fees. If Pavel's block stays outside the active chain, its coinbase reward cannot be spent in that history. It does not move to the Mempool like an ordinary payment. Meanwhile, Pavel cannot recover the electricity he used. Miners therefore care not just about finding a block, but also about getting the news to everyone else quickly. [1] [2]

Articles and block explorers sometimes use Orphan Block as another name for a Stale Block. The terms are often treated as synonyms, but a more precise distinction matters. An Orphan Block is a block whose predecessor is not yet known to a node, so the node cannot yet connect it. A Stale Block can have a known predecessor and be valid; it simply lies outside the selected branch. The word orphan is also used for transactions when a node lacks earlier transactions needed to verify their inputs. Always check which meaning the source intends. [1]

If a node was already using Pavel's block and then replaces it with Anna's branch, it performs a Reorg: it changes part of the history it treats as active. This is why a wallet's confirmation count can change. A short race like our example can happen with honest mining. An attacker can, however, try to use a change of history for a Double Spend, replacing a payment with another spending the same funds. A Stale Block alone does not demonstrate that intent. The sequence of events and any conflicting transactions need to be examined. [1] [2]

News of a new block does not travel around the world instantly. The longer it takes, the longer other miners may unknowingly keep working on the same predecessor. Transmission speed, connections between nodes and propagation time relative to the interval between blocks all matter. Stale Rate is the proportion of discovered valid blocks that do not remain in the active chain. It is not a fixed percentage specified by Bitcoin's rules. Comparisons also depend on the observation period and which blocks the observer actually saw. [1] [3]

The BIP152 specification describes Compact Block Relay. A node often already knows most transactions in a new block from its Mempool, so their full contents need not be sent again. Short identifiers let it reconstruct the block from data it has, then request any missing transactions. This saves bandwidth and, under suitable conditions, lets nodes learn about new blocks sooner. It helps with transmission; it does not change validity rules. It cannot completely prevent two miners from finding blocks almost simultaneously. [3]

The accumulated work of a branch is technically called chainwork. It is neither a measurement of electricity actually consumed nor a vote counted by computers. Each block contributes a value derived from the difficulty of its Proof of Work, the evidence of mining work. That is why “the longer chain wins” is less precise than “the valid branch with more chainwork wins.” A node must verify the rules: even a great deal of work cannot make invalid transactions valid. The label stale also describes a block's relationship to the history currently selected by a particular node. [1] [2]

A block explorer is a useful overview, but it shows the service's view. Your own Full Node, which checks the rules, lets you inspect the history you have independently accepted. If the node has the block data, Bitcoin Core’s getblock returns confirmations: -1 for a block outside the active chain. If the data is missing, for example because pruning removed it from storage, the command returns an error. That value alone does not prove the block passed every validity check. To identify its position precisely, also examine its hash — its identifier — predecessor, height (the number of blocks before it) and chainwork; check the fate of an individual payment separately. Two blocks can have the same height but different hashes. [4] [5]

For the clearest picture, read this entry together with Reorg, Confirmation, Block, Block Header, Proof of Work, Mining. The reverse links also lead from Reorg, Mining Pool, Hashrate, Selfish Mining.

DOC · 001Bitcoin Developer Guide — Block ChainDocumentation DOC · 002Bitcoin Core v29.0 — chain activation and mempool reconciliationPrimary DOC · 003BIP 152 — Compact Block RelaySpecification DOC · 004Bitcoin Core v29.0 — getblockDocumentation DOC · 005Bitcoin Core v29.0 — block RPC implementationPrimary
Revised: Source-first · No investment advice