W wąskim znaczeniu Orphan Block to blok, którego rodzica nie zna obserwujący węzeł. Szersze użycie myli go z blokiem stale na nieaktywnej gałęzi; sama nazwa nie określa poprawności ani przyczyny.
Bitcoin Developer Guide wyraźnie odróżnia Orphan Block z nieznanym rodzicem od Stale Block na konkurencyjnej gałęzi. Drugi może mieć znanego rodzica i być poprawny. Czytając eksplorator lub raport puli, najpierw ustal znaczenie użyte przez autora; samo słowo orphan tego nie rozstrzyga. [Bitcoin Developer Guide — Block height and forks]
Bitcoin Core 29 w AcceptBlockHeader wyszukuje hashPrevBlock w indeksie. Brak wpisu zwraca prev-blk-not-found; rodzic oznaczony jako niepoprawny prowadzi do bad-prevblk. To różne wyniki. Uzyskanie rodzica umożliwia dalsze kontrole kontekstowe, ale samo jeszcze nie gwarantuje przyjęcia całego bloku. [Bitcoin Core 29 — Header acceptance]
Bitcoin Core 0.10.0 wprowadził synchronizację headers-first: najpierw nagłówki, potem równoległe pobieranie bloków. Indeks może więc znać nagłówek rodzica bez jego pełnego bloku na dysku. Nie myl brakującej treści bloku z nieznanym nagłówkiem rodzica; ustal, jakich danych naprawdę brakuje. [Bitcoin Core 0.10.0 — Headers-first synchronization]
W getchaintips Bitcoin Core 29 rozróżnia active, valid-fork, valid-headers, headers-only i invalid. valid-fork jest w pełni zweryfikowaną gałęzią nieaktywną; valid-headers ma dostępne bloki bez pełnej weryfikacji, a headers-only nie ma wszystkich bloków. Nawet sformułowanie orphaned branches w pomocy nie uzasadnia łączenia tych stanów. [Bitcoin Core 29 — getchaintips]
Przykład: różne bloki A i B mogą mieć wysokość 900000. Liczba nie wskazuje zwycięzcy ani jednoznacznej tożsamości; zapisuj hash i previousblockhash. O wyborze między poprawnymi gałęziami decyduje skumulowana praca, opisana w RPC jako chainwork, nie sama wysokość. Liczba przykładu nie wskazuje konkretnego historycznego rozwidlenia. [Bitcoin Developer Guide — Block height and forks] [Bitcoin Core 29 — getblock]
getblock w Bitcoin Core 29 zwraca confirmations = -1 dla bloku poza głównym łańcuchem. Nie jest to ujemna głębokość reorganizacji ani dowód braku rodzica. Czytaj wynik wraz z hashem, danymi gałęzi i stanem lokalnego węzła; jego wynik nie wylicza wszystkiego, co odebrały inne węzły. [Bitcoin Core 29 — getblock]
COINBASE_MATURITY w Bitcoin Core 29 wynosi 100. Ogranicza wydawanie wyjścia coinbase według głębokości w blokach, a nie minut oczekiwania. Upływ czasu lub kolejne bloki gdzie indziej nie przywracają nagrody z gałęzi stale poza aktywną historią; dojrzałość nie zastępuje włączenia do łańcucha. [Bitcoin Core 29 — Coinbase maturity] [Bitcoin Developer Guide — Block height and forks]
W swoim zapisie połącz getchaintips i getblock z hashem bloku, rodzicem, stanem gałęzi, wersją węzła i czasem obserwacji. Zapisz ten czas oddzielnie od pola time nagłówka. Jeden wynik nie dowodzi ataku, globalnego udziału sierot ani konkretnej awarii sieci; potrzebne są dalsze obserwacje. [Bitcoin Core 29 — getchaintips] [Bitcoin Core 29 — getblock]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Stale Block, Reorg, Block propagation, Proof of Work. Do tego hasła prowadzą również odsyłacze z Stale Block.