getblocktemplate to interfejs, przez który oprogramowanie otrzymuje od węzła sieci Bitcoin dane do złożenia kandydata na blok. Korzysta z JSON-RPC, czyli żądania i uporządkowanej odpowiedzi wymienianych między programami. Zwykły tryb dostarcza szablon; osobny pozwala wstępnie ocenić własną propozycję. Żaden sam nie szuka dowodu pracy.
W zwykłym trybie mode=template program Piotra otrzymuje między innymi poprzedni blok, transakcje i dozwoloną nagrodę. To propozycja zadania, a nie znaleziony już blok. Oprogramowanie musi utworzyć coinbase, specjalną pierwszą transakcję przyznającą nagrodę, i dokończyć składanie bloku. Nagłówek zawiera zwięzłe podsumowanie danych bloku. Program szuka następnie hasha, czyli liczbowego skrótu kryptograficznego tego nagłówka, który spełni cel wydobycia i będzie stanowił Proof of Work, dowód wykonanej pracy obliczeniowej. Samo getblocktemplate nie przyjmuje adresu wypłaty ani nie uruchamia obliczeń koparki. Poprawna odpowiedź nie oznacza więc jeszcze, że Piotr wydobywa. [1]
Wyobraźmy sobie, że węzeł przesyła dane w formie niezrozumiałej dla programu Piotra. Dlatego żądanie podaje obsługiwane reguły w polu rules. Sprawdzona tutaj wersja Bitcoin Core v29.0 wymaga segwit, a dla sieci testowej Signet również signet. SegWit zmienia między innymi sposób obsługi danych służących do weryfikacji transakcji. Dopisanie właściwego słowa nie wystarczy: program musi rzeczywiście umieć je przetwarzać. capabilities zgłasza inne możliwości interfejsu i nie zastępuje rules. Dokładne wymagania zależą od użytej implementacji i wersji. [2]
Pole data zawiera pełny zapis transakcji uporządkowany do przesłania między programami. Takie uporządkowanie nazywa się serializacją. Bajty, podstawowe jednostki tych danych, są zapisane szesnastkowo za pomocą cyfr 0–9 i liter a–f. Odpowiedź zawiera również krótkie identyfikatory transakcji. Według dokumentu technicznego BIP 145 txid jest obliczany bez danych witness, natomiast hash je uwzględnia. Witness obejmuje na przykład podpisy potwierdzające uprawnienie do wydania środków. Główny Merkle root, zbiorczy skrót transakcji w nagłówku bloku, wykorzystuje txid, a nie witness hash. Pomylenie pól to nie tylko pomyłka w nazwie: może dać błędny skrót zbiorczy i sprawić, że złożony blok będzie nieprawidłowy. [3]
Piotr nie musi zasypywać węzła pytaniami, czy coś się zmieniło. Long polling utrzymuje żądanie otwarte, aż serwer zechce zastąpić poprzednie dane. Program odbiera longpollid i odsyła go bez zmian. Ta wartość wskazuje serwerowi, na jaką zmianę czeka program. Program nie powinien próbować odczytywać znaczenia z zawartych w niej znaków. BIP 22 przewiduje długi limit oczekiwania. Powtarzające się niepełne lub błędne odpowiedzi wymagają przerw między próbami, a nie natychmiastowego ponawiania w pętli. Sama cisza podczas oczekiwania nie oznacza zatem awarii. [4]
Nawet zwykłe powtórzenie żądania nie gwarantuje świeżo dobranej zawartości. Bitcoin Core v29.0 przechowuje przygotowany szablon w pamięci podręcznej. Tworzy go ponownie, gdy zmienia się poprzedni blok albo gdy zmienił się mempool, lokalny zbiór niepotwierdzonych transakcji, i od przygotowania minęło ponad pięć sekund. Czas w nagłówku może aktualizować osobno. Piotr może więc ponownie otrzymać ten sam zestaw transakcji; nie świadczy to o zawieszeniu węzła. To zachowanie konkretnej wersji nie obiecuje również unikalnego zadania wydobywczego przy każdym wywołaniu. [2]
Piotr zmienił sposób składania bloku i chce wykryć błędy przed kosztownym szukaniem wyniku. W trybie proposal przekazuje cały blok w zapisie szesnastkowym w polu data. Bitcoin Core v29.0 sprawdza również Merkle root, lecz nie wymaga już znalezionego poprawnego Proof of Work, dowodu pracy obliczeniowej. Jeśli propozycja nie nawiązuje do ostatniego bloku łańcucha używanego obecnie przez węzeł, zwraca inconclusive-not-best-prevblk. Oznacza to brak warunku koniecznego do tej kontroli, a nie pełną ocenę poprawności propozycji. Wstępna kontrola nie rozsyła też bloku po sieci. [2]
Po znalezieniu wymaganego dowodu pracy program może przekazać cały blok przez submitblock. hexdata zawiera kompletny zserializowany blok zapisany szesnastkowo, a nie tylko nagłówek czy skrót. Dokumentacja Bitcoin Core 29 podaje null w przypadku przyjęcia, a w pozostałych przypadkach wynik tekstowy zgodny ze specyfikacją. Opcjonalny drugi parametr dummy jest ignorowany; nie służy do ustalania nagrody. Przyjęcie przez węzeł nie gwarantuje trwałego potwierdzenia: dalszy rozwój łańcucha może zmienić to, która gałąź pozostanie główna. [5]
Świeżo uruchomiony węzeł może jeszcze nie mieć pobranej i zweryfikowanej potrzebnej historii. W sieci głównej, mainnet, Bitcoin Core v29.0 odmawia wydania szablonu bez połączonych partnerów lub podczas początkowej synchronizacji IBD (initial block download). Chodzi o gotowość węzła do pracy z bieżącą siecią, nie o odrzucenie konkretnego bloku. Przy diagnozowaniu problemu rozróżniamy więc oczekujący long poll, niegotowy węzeł i wynik kontroli propozycji. Wszystkie mogą wyglądać jak „brak nowej pracy”, ale wymagają innych działań. [2]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Block Template, Wydobywanie, Stratum V2, Extranonce, Bitcoin, Bitcoin Core. Do tego hasła prowadzą również odsyłacze z ASIC Miner, Solo Mining, Job Negotiation.