227 / 691BTPL

Block Template

Dane do złożenia kandydata na blok

Block Template opisuje kandydata na następny blok, jego transakcje i warunki zmian. Po zmianie zawartości nie wystarczy skopiować starej nagrody i hashy: wszystkie zależne dane muszą odpowiadać wynikowemu blokowi.

Block Template to zestaw danych do złożenia bloku, dla którego nagłówka szuka się proof of work. Łączy poprzedni blok, transakcje, coinbase i ograniczenia kopania; nie dowodzi znalezienia ani przyjęcia bloku.

Pola previousblockhash i height umiejscawiają kandydata w łańcuchu. Są też version, bits i dane czasowe. Szablon służy do składania bloku, nie jest jedynie gotowym nagłówkiem do bezmyślnego powtarzania tego samego obliczenia. [BIP 22 — Block template structure]

W BIP 22 depends odsyła indeksami od jedynki do wcześniejszych elementów transactions, bez coinbase w tej liście. Gdy transakcja potomna wydaje wyjście rodzica zawartego w tym samym bloku, rodzic musi ją poprzedzać. Brak depends oznacza nieznane zależności, nie ich nieistnienie. [BIP 22 — Block template structure]

Bitcoin Core v29.0 buduje coinbase z subsydium dla danej wysokości i rzeczywistych opłat uwzględnionych transakcji. Po ich usunięciu nie można automatycznie zachować starego coinbasevalue jako należnej nagrody. Zmiana wyboru wymaga przeliczenia dostępnych opłat. [Bitcoin Core v29.0 — Block assembler]

Według BIP 141 witness commitment wiąże dane witness przez wtxid. Bitcoin Core 29 podaje default_witness_commitment dla niezmienionego szablonu. Po zmianie odpowiednich transakcji lub ich kolejności należy sprawdzić albo przeliczyć zobowiązanie i uwzględnić wynikowe TXID w Merkle root nagłówka. [BIP 141 — Witness commitment] [Bitcoin Core 29 — getblocktemplate RPC]

Bitcoin Core v29.0 wybiera pakiety z zależnościami, przestrzegając wagi i sigops. blockmaxweight oraz blockmintxfee wpływają na składanie. Pominięcie transakcji przez tę politykę samo nie dowodzi niezgodności z konsensusem; konfiguracja górnika nie podnosi limitów sieci. [Bitcoin Core v29.0 — Block assembler]

BIP 23 używa mutable do opisu dozwolonych zmian, na przykład czasu lub transakcji. Zgoda serwera nie znosi konsensusu: poprzednik, czas, trudność i transakcje nadal muszą być poprawne. Dostęp do szablonu nie gwarantuje też urządzeniu końcowemu nieograniczonego wyboru zawartości. [BIP 23 — Mutations and proposals]

BIP 23 może ograniczać pracę przez expires i określać uprawnienie do zmiany prevblock. Po zmianie końca łańcucha podmiana samego hasha poprzednika nie zapewnia poprawności reszty. Trzeba ponownie ocenić wysokość, transakcje, nagrodę i inne warunki kontekstowe. [BIP 23 — Mutations and proposals]

Tryb proposal w BIP 23 sprawdza propozycję bez wymagania poprawnego proof of work. Pozytywny wynik nie oznacza znalezienia ani publikacji bloku, ani trwałego miejsca w łańcuchu. Gotowy blok musi przejść właściwą walidację przy zgłoszeniu. [BIP 23 — Mutations and proposals]

Pełniejszy obraz uzyskasz, czytając to hasło razem z Mining Pool, Nagłówek bloku, Extranonce, Drzewo Merkle. Do tego hasła prowadzą również odsyłacze z Transakcja coinbase, ASIC Miner, Mining Pool, Nonce.

DOC · 001BIP 22 — Block template structureSpecyfikacja ↗DOC · 002BIP 23 — Mutations and proposalsSpecyfikacja ↗DOC · 003Bitcoin Core 29 — getblocktemplate RPCDokumentacja ↗DOC · 004Bitcoin Core v29.0 — Block assemblerŹródło pierwotne ↗DOC · 005BIP 141 — Witness commitmentSpecyfikacja ↗
Najpierw źródła · To nie jest porada inwestycyjna