W ścisłym znaczeniu Orphan Block to blok, którego bezpośredniego poprzednika dany węzeł nie zna. Potocznie określa się tak również Stale Block poza aktywnym łańcuchem. Żadna z tych etykiet sama nie oznacza oszustwa ani wadliwego bloku; najpierw trzeba ustalić, jakie dane ma węzeł i o którym znaczeniu mówimy.
Poprzedni blok bywa nazywany rodzicem. Przy rzeczywistym Orphan Block węzeł Jany go nie zna i nie może dokończyć sprawdzania powiązania. Stale Block może mieć znanego rodzica i być całkowicie poprawny; węzeł po prostu uznaje inną gałąź za aktywną historię. Bitcoin Developer Guide wyraźnie odróżnia te znaczenia. Gdy Jana widzi orphan w eksploratorze bloków, najpierw pyta, czy brakuje poprzednika, czy blok jedynie nie utrzymał się w głównym łańcuchu. [1]
Różnicę widać także w Bitcoin Core, oprogramowaniu do uruchamiania węzła sprawdzającego bloki i transakcje zgodnie z regułami Bitcoina. W Bitcoin Core 29 funkcja AcceptBlockHeader szuka poprzednika przez hashPrevBlock, odwołanie do jego identyfikującego odcisku. Jeśli indeks nie ma wpisu, zwraca prev-blk-not-found. Jeśli rodzic jest znany i oznaczony jako niepoprawny, wynikiem jest bad-prevblk. Pierwszy przypadek mówi „brakuje mi kontekstu”, drugi „opierasz się na niepoprawnym bloku”. Dostarczenie brakującego poprzednika umożliwia dalsze kontrole, ale samo nie gwarantuje przyjęcia całego bloku. [2]
Blok ma nagłówek, krótki zestaw danych o tożsamości i powiązaniach, oraz część zawierającą transakcje. Bitcoin Core 0.10.0 wprowadził synchronizację headers-first: najpierw pobiera się i sprawdza nagłówki, a potem można równolegle pobierać bloki. Węzeł Jany może więc znać nagłówek poprzednika, choć nie ma jeszcze całego bloku na dysku. Brak zawartości bloku nie jest tym samym co nieznany poprzednik; pomylenie tych sytuacji mogłoby zamienić zwykłe pobieranie danych w pozorną zagadkę. [3]
Polecenie getchaintips w Bitcoin Core 29 pokazuje Janie, jakie końce gałęzi zna jej węzeł. active oznacza aktywny łańcuch, a valid-fork w pełni sprawdzoną nieaktywną gałąź. valid-headers mówi, że bloki są dostępne, ale nie zostały całkowicie zweryfikowane; headers-only oznacza brak niektórych bloków. invalid wskazuje gałąź z niepoprawnym blokiem. Nie jest to zatem lista jednakowych problemów. Nawet sformułowanie orphaned branches w pomocy nie znosi tych różnic. [4]
Wyobraźmy sobie dwa różne bloki A i B na wysokości 900000. To nasz własny przykład, nie opis konkretnego zdarzenia. Wysokość jest pozycją w łańcuchu, więc konkurujące bloki mogą mieć tę samą wysokość. Jana rozróżnia je za pomocą hash, identyfikującego odcisku bloku, i previousblockhash, odwołania do poprzednika. O wyborze między poprawnymi gałęziami decyduje skumulowana praca, nie sama wysokość. Interfejs RPC, służący do wydawania programowi poleceń, podaje ją jako chainwork: sumę oczekiwanej pracy odpowiadającej trudnościom bloków. [1] [5]
Gdy Jana pyta przez getblock o blok poza głównym łańcuchem, Bitcoin Core 29 może zwrócić confirmations = -1. To specjalne oznaczenie stanu, nie zwykła liczba potwierdzeń. Nie jest odliczaniem ani ujemną głębokością reorganizacji łańcucha. Nie dowodzi też braku poprzednika. Jana musi odczytać tę wartość wraz z tożsamością bloku i stanem gałęzi; jej węzeł może ponadto nie mieć wszystkich bloków, które kiedykolwiek widzieli inni uczestnicy. [5]
Nagroda za blok powstaje w specjalnej pierwszej transakcji coinbase, niezwiązanej z giełdą o tej samej nazwie. Wyjście transakcji zapisuje określoną kwotę w bitcoinach oraz warunki, które trzeba spełnić, aby ją wydać. W Bitcoin Core 29 COINBASE_MATURITY wynosi 100: wyjście utworzone na wysokości H można po raz pierwszy wydać w poprawnym bloku na wysokości H+100. Liczy się różnica wysokości, nie minuty. Ten okres oczekiwania nie zastępuje jednak obecności w aktywnym łańcuchu. Dopóki blok z nagrodą pozostaje na nieaktywnej gałęzi, jego wyjścia nie ma w aktywnym zbiorze UTXO, ewidencji niewydanych wyjść. Kolejne bloki gdzie indziej same nie przywrócą tych pieniędzy. [6] [7] [1] [8]
Jana zapisuje hash bloku, jego poprzednika, stan gałęzi i wersję programu. Dołącza odpowiedzi getchaintips i getblock oraz czas ich uzyskania. Notuje go oddzielnie od pola time w nagłówku: znacznik czasu bloku nie jest chwilą, gdy jej komputer go zaobserwował. Taki zapis pomaga porównywać kolejne obserwacje, lecz sam nie dowodzi ataku, konkretnej awarii sieci ani globalnego udziału bloków orphan. Przede wszystkim opisuje stan jednego węzła w danej chwili. [4] [5]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Stale Block, Reorg, Block Propagation, Proof of Work, Bitcoin. Do tego hasła prowadzą również odsyłacze z Stale Block.