Strictly, an Orphan Block is a block whose immediate predecessor is unknown to a particular node. More loosely, the term sometimes means a Stale Block, outside the active chain. Neither label alone implies fraud or a defective block; first we need to know what data the node has and which meaning is intended.
The preceding block is sometimes called the parent. For a true Orphan Block, Jana’s node does not know it and cannot finish checking the connection. A Stale Block can have a known parent and be entirely valid; the node simply follows a different branch as its active history. The Bitcoin Developer Guide explicitly distinguishes these meanings. When Jana sees orphan in a block explorer, she first asks whether the predecessor is missing or the block merely failed to remain in the main chain. [1]
The distinction also appears in Bitcoin Core, software for running a node that checks blocks and transactions against Bitcoin’s rules. In Bitcoin Core 29, AcceptBlockHeader looks up the predecessor through hashPrevBlock, the reference to its identifying fingerprint. If the index has no record, it returns prev-blk-not-found. If the parent is known and marked invalid, the result is bad-prevblk. The first means “I lack the context”; the second means “you build on an invalid block.” Supplying the missing predecessor enables further checks but does not by itself guarantee acceptance of the complete block. [2]
A block has a header, a short set of identifying and linking information, and a body containing transactions. Bitcoin Core 0.10.0 introduced headers-first synchronization: headers are obtained and checked first, after which blocks can be downloaded in parallel. Jana’s node can therefore know the predecessor’s header without yet having the whole block on disk. A missing block body is not the same as an unknown predecessor; confusing them could make ordinary downloading seem mysterious. [3]
The getchaintips command in Bitcoin Core 29 helps Jana see which branch tips her node knows. active marks the active chain; valid-fork is a fully validated inactive branch. valid-headers means the blocks are available but have not been fully validated; headers-only means some blocks are unavailable. invalid identifies a branch containing an invalid block. This is not one list of equally problematic results. Even the phrase orphaned branches in the help text does not erase these distinctions. [4]
Imagine two different blocks, A and B, at height 900000. This is our own illustration, not an account of a particular event. Height is a position in the chain, so competing blocks can share it. Jana distinguishes them using hash, the block’s identifying fingerprint, and previousblockhash, its predecessor reference. Selection between valid branches depends on cumulative work, not just height. The RPC interface used to give the software commands reports this as chainwork: accumulated expected work corresponding to the blocks’ difficulties. [1] [5]
When Jana queries a block outside the main chain with getblock, Bitcoin Core 29 may report confirmations = -1. This is a special status marker, not an ordinary confirmation count. It is neither a countdown nor a negative depth of chain reorganization. It does not prove a missing predecessor either. Jana needs to read it alongside the block’s identity and branch status; her node may not possess every block other participants have ever seen. [5]
The block reward is created by a special initial transaction called coinbase, unrelated to the exchange of that name. A transaction output records an amount of bitcoin and the conditions that must be met to spend it. In Bitcoin Core 29, COINBASE_MATURITY is 100: an output created at height H can first be spent in a valid block at H+100. The height difference matters, not elapsed minutes. This waiting condition does not replace inclusion in the active chain. While the reward block remains on an inactive branch, its output is absent from the active UTXO set, the record of unspent outputs. More blocks elsewhere do not restore the money by themselves. [6] [7] [1] [8]
Jana records the block hash, predecessor, branch status and software version. She adds the getchaintips and getblock responses and the time she obtained them. That time is separate from the header’s time field: a block’s timestamp is not when her computer observed it. Such a record helps compare further observations, but does not alone prove an attack, a specific network fault or a worldwide orphan rate. First and foremost, it describes one node’s state at a particular moment. [4] [5]
For the clearest picture, read this entry together with Stale Block, Reorg, Block Propagation, Proof of Work, Bitcoin. The reverse links also lead from Stale Block.