233 / 691ORPH

Orphan Block

Блок с неизвестным родителем; также неоднозначное название блока боковой ветви

Orphan Block может означать отсутствие родительского контекста или, в широком употреблении, конкурирующий блок вне активной цепи. Различие определяет, что узел действительно проверил и какие выводы допускает его выдача.

В узком смысле 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.

DOC · 001Bitcoin Developer Guide — Block height and forksДокументация ↗DOC · 002Bitcoin Core 29 — Header acceptanceПервичный источник ↗DOC · 003Bitcoin Core 0.10.0 — Headers-first synchronizationПервичный источник ↗DOC · 004Bitcoin Core 29 — getchaintipsДокументация ↗DOC · 005Bitcoin Core 29 — getblockДокументация ↗DOC · 006Bitcoin Core 29 — Coinbase maturityПервичный источник ↗
Сначала источники · Не является инвестиционной рекомендацией