In its narrower sense, Orphan Block is a block whose parent the observing node does not know. Broader usage confuses it with a stale block on an inactive branch; the label alone therefore establishes neither validity nor cause.
Bitcoin Developer Guide explicitly separates a true Orphan Block with an unknown parent from a Stale Block on a competing branch. The latter may have a known parent and be valid. When reading an explorer or pool report, first establish which meaning its author uses; the word orphan does not settle that distinction. [Bitcoin Developer Guide — Block height and forks]
Bitcoin Core 29 looks up hashPrevBlock in its index in AcceptBlockHeader. A missing entry returns prev-blk-not-found; a parent marked invalid leads to bad-prevblk. These are different results. Obtaining the parent permits further contextual checks but does not itself guarantee acceptance of the entire block. [Bitcoin Core 29 — Header acceptance]
Bitcoin Core 0.10.0 introduced headers-first synchronization: headers first, then parallel block downloads. The index can thus know the parent header without its full block on disk. Do not confuse a missing block body with an unknown parent header; identify which data are actually missing. [Bitcoin Core 0.10.0 — Headers-first synchronization]
In getchaintips, Bitcoin Core 29 distinguishes active, valid-fork, valid-headers, headers-only and invalid. valid-fork is a fully validated inactive branch; valid-headers has available blocks without full validation, while headers-only lacks some blocks. Even the help phrase orphaned branches does not justify merging these states into one category. [Bitcoin Core 29 — getchaintips]
Illustration: different blocks A and B may both have height 900000. That number alone identifies neither the winner nor a unique block; record hash and previousblockhash. Selection between valid branches follows accumulated work, described in RPC as chainwork, not simply height. The illustrative number does not assert a particular historical fork. [Bitcoin Developer Guide — Block height and forks] [Bitcoin Core 29 — getblock]
Bitcoin Core 29 getblock returns confirmations = -1 for a block outside the main chain. This is neither a negative reorganization depth nor proof of a missing parent. Read it alongside the hash, branch information and local node state; one node’s output does not list everything other nodes have received. [Bitcoin Core 29 — getblock]
COINBASE_MATURITY in Bitcoin Core 29 is 100. It restricts spending a coinbase output by block depth, not by waiting minutes. Time passing or additional blocks appearing elsewhere does not restore the reward of a stale branch outside active history; maturity does not replace inclusion in the chain. [Bitcoin Core 29 — Coinbase maturity] [Bitcoin Developer Guide — Block height and forks]
For your record, combine getchaintips and getblock with block hash, parent, branch status, node version and observation time. Record observation time separately from the header time field. A single such output does not establish an attack, a global orphan rate or a specific network failure; those require further observations. [Bitcoin Core 29 — getchaintips] [Bitcoin Core 29 — getblock]
For the clearest picture, read this entry together with Stale block, Chain reorganization, Block propagation, Proof of Work. The reverse links also lead from Stale block.