Block Template

Każdy nowy blok opiera się na konkretnym poprzedniku. W szablonie wskazuje go previousblockhash, jego unikalny skrót kryptograficzny, a height podaje pozycję proponowanego bloku w łańcuchu. Pozostałe pola obejmują version, wersję nagłówka, bits, skrócony zapis celu dla wyniku wydobycia, oraz dane czasu. To informacje do zbudowania konkretnego bloku, nie niezależna lista płatności. Te same transakcje umieszczone po innym poprzedniku tworzą już inne zadanie. [1]

Anna otrzymuje bitcoina, a następnie nim płaci. Jeśli oba przelewy mają znaleźć się w tym samym bloku, najpierw musi wystąpić transakcja przydzielająca jej środki, a dopiero później ta, która je wydaje. BIP 22, dokument techniczny opisujący format szablonu, definiuje dla takich zależności pole depends: pole wskazuje wcześniejsze pozycje listy transactions, numerowane od jedynki. Lista nie obejmuje coinbase, specjalnej pierwszej transakcji przypisującej nagrodę górnikowi. Brak depends oznacza nieznane zależności, a nie potwierdzenie, że ich nie ma. Oprogramowanie nie może uznać brakującej informacji za pustą listę. [1]

Nagroda obejmuje nowo emitowane bitcoiny zgodnie z zasadami danej wysokości oraz opłaty transakcji rzeczywiście zawartych w bloku. Tak oblicza ją również przywołany Bitcoin Core v29.0. To oprogramowanie sprawdza bloki i transakcje oraz może przygotowywać szablony do wydobycia. W naszym przykładzie transakcje przynoszą 10000 sats; po usunięciu niezależnej transakcji z opłatą 3000 sats pozostaje 7000 sats opłat. Sats to drobne jednostki bitcoina. Pole coinbasevalue podaje maksymalną nagrodę, jaką górnik może sobie przypisać przy pierwotnym zestawie transakcji. Po zmianie tego zestawu trzeba ponownie obliczyć kwotę. Trzeba uwzględnić rzeczywiste opłaty, a nie sumę wyliczoną dla starej zawartości. [4] [1]

Blok zawiera też skróty kryptograficzne umożliwiające sprawdzenie danych. BIP 141 opisuje witness commitment, wiążący skrót danych witness, do których należą na przykład podpisy potwierdzające prawo do wydania środków. Powstaje on na podstawie identyfikatorów wtxid obejmujących te dane. Bitcoin Core 29 udostępnia default_witness_commitment dla niezmienionego szablonu. Po zmianie odpowiednich transakcji lub ich kolejności trzeba ten skrót sprawdzić albo przeliczyć. Merkle root, czyli zbiorczy skrót transakcji w nagłówku, trzeba też obliczyć na podstawie ostatecznych identyfikatorów TXID, w tym identyfikatora zmienionej coinbase. Stara pieczęć nie pasuje do zmienionej treści. [5] [3]

Miejsce w bloku jest ograniczone, a górnik wybiera jego zawartość. Bitcoin Core v29.0 ocenia pakiety powiązanych transakcji, ich wagę, czyli miarę obciążenia danymi, oraz sigops, czyli operacje weryfikacji podpisów wliczane do limitu bloku. Ustawienia blockmaxweight i blockmintxfee wpływają na wielkość budowanego bloku i wymaganą stawkę opłaty. To polityka wyboru. Pominięta z tego powodu płatność nie musi naruszać reguł sieci. Własne ustawienia górnika nie zwiększają też limitów sieciowych sprawdzanych przez pozostałe węzły. [4] [3]

W BIP 23 pole mutable wymienia zmiany dozwolone przez serwer, na przykład korektę czasu lub dodanie transakcji. To umowa dotycząca pracy z konkretnym szablonem. Zgoda serwera nie uchyla konsensusu, czyli reguł poprawności niezależnie sprawdzanych przez innych uczestników. Poprzednik, czas, trudność i transakcje nadal muszą się zgadzać. Dostęp do szablonu nie oznacza również, że każde podłączone urządzenie może dowolnie zmieniać jego treść; zależy to od organizacji systemu i przekazanego zadania. [2]

Podczas obliczeń inny górnik może wydłużyć łańcuch. Aby dalej pracować nad następcą najnowszego zaakceptowanego bloku, nie wystarczy podmienić skrótu poprzedniego bloku w starej propozycji. Niektóre transakcje mogą już być potwierdzone, zmienia się wysokość i inne warunki. BIP 23 opisuje expires jako czasowy limit pracy, a prevblock jako pozwolenie użycia jej z innym poprzednikiem. Nawet taka zgoda nie zastępuje weryfikacji: trzeba ponownie ocenić transakcje, nagrodę i cały nowy kontekst. [2]

Błąd w projekcie lepiej wykryć przed długim szukaniem. Tryb proposal według BIP 23 pozwala przedstawić go do sprawdzenia bez poprawnego Proof of Work, czyli bez znalezionego już wyniku dowodzącego wymaganej pracy obliczeniowej. Pozytywna ocena nie oznacza znalezienia ani rozesłania bloku, ani zagwarantowania mu trwałego miejsca w łańcuchu. Mówi, że projekt przeszedł odpowiednią kontrolę wstępną. Gotowy blok musi następnie przejść właściwą weryfikację przy zgłoszeniu, łącznie z dowodem pracy. [2]