狭义的 Orphan Block 是观察节点尚不知道其父区块的区块。广义用法常将它与非活跃分支上的 stale 区块混淆，因此名称本身既不能确定有效性，也不能说明原因。
Bitcoin Developer Guide 明确区分父区块未知的 Orphan Block 与竞争分支上的 Stale Block。后者的父区块可能已知，而且区块可能有效。阅读区块浏览器或矿池报告时，应先确认作者使用哪种含义；orphan 一词本身不能划清这条界线。 [Bitcoin Developer Guide — Block height and forks]
Bitcoin Core 29 在 AcceptBlockHeader 中通过索引查找 hashPrevBlock。缺少记录会返回 prev-blk-not-found；父区块被标记为无效则产生 bad-prevblk。这是不同结果。获取父区块后可以继续进行上下文检查，但并不自动保证整个区块被接受。 [Bitcoin Core 29 — Header acceptance]
Bitcoin Core 0.10.0 引入 headers-first 同步：先获取区块头，再并行下载区块。因此，索引可能已知父区块头，但磁盘尚无其完整区块。缺少区块体不能等同于父区块头未知；必须明确究竟缺少哪些数据。 [Bitcoin Core 0.10.0 — Headers-first synchronization]
在 getchaintips 中，Bitcoin Core 29 区分 active、valid-fork、valid-headers、headers-only 和 invalid。valid-fork 是已完全验证的非活跃分支；valid-headers 的区块均可用但尚未完全验证，headers-only 则缺少部分区块。即使帮助文本使用 orphaned branches，也不能把这些状态合并为一类。 [Bitcoin Core 29 — getchaintips]
示例：不同区块 A 和 B 都可能处于高度 900000。这个数字既不确定胜者，也不是唯一标识；应保存 hash 和 previousblockhash。在有效分支之间进行选择依据的是累计工作量，RPC 中称为 chainwork，而不只是高度。示例数字并不声称存在某次具体历史分叉。 [Bitcoin Developer Guide — Block height and forks] [Bitcoin Core 29 — getblock]
Bitcoin Core 29 的 getblock 对不在主链上的区块返回 confirmations = -1。它既不是负的重组深度，也不能证明父区块缺失。应结合哈希、分支信息和本地节点状态解读；单个节点的输出并不列出其他节点接收到的所有内容。 [Bitcoin Core 29 — getblock]
Bitcoin Core 29 中 COINBASE_MATURITY 为 100。它按区块深度限制 coinbase 输出的花费，而不是要求等待若干分钟。仅仅经过时间或别处产生更多区块，不会恢复活跃历史之外 stale 分支的奖励；成熟条件不能代替被纳入链中。 [Bitcoin Core 29 — Coinbase maturity] [Bitcoin Developer Guide — Block height and forks]
记录时，将 getchaintips 和 getblock 与区块哈希、父区块、分支状态、节点版本及观察时间结合。观察时间应与区块头的 time 字段分开保存。单次输出本身不能证明攻击、全网孤块率或具体网络故障；这些判断需要更多观察。 [Bitcoin Core 29 — getchaintips] [Bitcoin Core 29 — getblock]
要获得更完整的理解，请将本词条与以下词条结合阅读： 陈旧区块, 链重组, 区块传播, Proof of Work. 反向关联还来自： 陈旧区块.