No sentido estrito, Orphan Block é um bloco cujo pai o nó observador desconhece. O uso amplo o confunde com um bloco stale em ramo inativo; o rótulo sozinho não determina validade nem causa.
Bitcoin Developer Guide distingue explicitamente um Orphan Block com pai desconhecido de um Stale Block em ramo concorrente. O segundo pode ter pai conhecido e ser válido. Ao ler um explorador ou relatório de pool, identifique primeiro o significado usado; a palavra orphan não resolve essa distinção. [Bitcoin Developer Guide — Block height and forks]
Bitcoin Core 29 procura hashPrevBlock no índice em AcceptBlockHeader. Uma entrada ausente retorna prev-blk-not-found; um pai marcado como inválido leva a bad-prevblk. São resultados diferentes. Obter o pai permite outras verificações de contexto, mas por si só não garante a aceitação do bloco inteiro. [Bitcoin Core 29 — Header acceptance]
Bitcoin Core 0.10.0 introduziu sincronização headers-first: primeiro cabeçalhos, depois downloads paralelos de blocos. Assim, o índice pode conhecer o cabeçalho do pai sem seu bloco completo no disco. Não confunda corpo de bloco ausente com cabeçalho parental desconhecido; determine quais dados realmente faltam. [Bitcoin Core 0.10.0 — Headers-first synchronization]
Em getchaintips, Bitcoin Core 29 distingue active, valid-fork, valid-headers, headers-only e invalid. valid-fork é um ramo inativo totalmente validado; valid-headers tem blocos disponíveis sem validação completa, enquanto headers-only não tem todos os blocos. Nem a expressão orphaned branches da ajuda justifica reunir esses estados numa categoria. [Bitcoin Core 29 — getchaintips]
Ilustração: blocos diferentes A e B podem ter altura 900000. O número não identifica o vencedor nem um bloco único; registre hash e previousblockhash. A escolha entre ramos válidos segue o trabalho acumulado, descrito em RPC como chainwork, não apenas a altura. O número ilustrativo não afirma uma bifurcação histórica específica. [Bitcoin Developer Guide — Block height and forks] [Bitcoin Core 29 — getblock]
getblock no Bitcoin Core 29 retorna confirmations = -1 para um bloco fora da cadeia principal. Isso não é profundidade negativa de reorganização nem prova de pai ausente. Leia junto com o hash, os dados do ramo e o estado local; a saída de um nó não lista tudo que outros nós receberam. [Bitcoin Core 29 — getblock]
COINBASE_MATURITY no Bitcoin Core 29 vale 100. A regra restringe o gasto de uma saída coinbase pela profundidade em blocos, não por minutos de espera. O tempo passar ou surgirem blocos em outro lugar não restaura a recompensa de ramo stale fora do histórico ativo; maturidade não substitui inclusão na cadeia. [Bitcoin Core 29 — Coinbase maturity] [Bitcoin Developer Guide — Block height and forks]
Para seu registro, combine getchaintips e getblock com hash do bloco, pai, estado do ramo, versão do nó e horário da observação. Registre esse horário separadamente do campo time do cabeçalho. Uma única saída não comprova ataque, taxa global de órfãos nem falha específica de rede; são necessárias mais observações. [Bitcoin Core 29 — getchaintips] [Bitcoin Core 29 — getblock]
Para ter uma visão mais completa, leia este verbete junto com Stale Block, Reorg, Block propagation, Proof of Work. Também há referências a este verbete em Stale Block.