У вузькому значенні 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]
getblock у Bitcoin Core 29 повертає confirmations = -1 для блока поза головним ланцюгом. Це не від’ємна глибина реорганізації й не доказ відсутнього батька. Читайте результат разом із хешем, даними гілки та станом локального вузла; його вивід не перелічує все, що отримали інші вузли. [Bitcoin Core 29 — getblock]
COINBASE_MATURITY у Bitcoin Core 29 дорівнює 100. Це обмеження витрачання виходу coinbase за глибиною в блоках, а не очікуванням у хвилинах. Плин часу або нові блоки деінде не відновлюють винагороду stale-гілки поза активною історією; зрілість не замінює включення в ланцюг. [Bitcoin Core 29 — Coinbase maturity] [Bitcoin Developer Guide — Block height and forks]
Для власного запису поєднайте getchaintips і getblock із хешем блока, батьком, станом гілки, версією вузла та часом спостереження. Записуйте цей час окремо від поля time заголовка. Один такий вивід не доводить атаки, глобальної частки orphan-блоків чи конкретного збою мережі; потрібні додаткові спостереження. [Bitcoin Core 29 — getchaintips] [Bitcoin Core 29 — getblock]
Для повної картини прочитайте також Stale Block, Reorg, Block propagation, Proof of Work. На цю статтю також посилаються Stale Block.