K popisu anatomie bitcoinové transakce byla náhodně vybrána segwitová
transakce
40e285bd2b757bf455f9e3ce92aa8e51910f88a1ca9dd497465d346310e7df11 z
bloku č. 676274. Jedná se o typickou transakci s jedním vstupem a
dvěma výstupy – to znamená, že transakce utrácí (spotřebovává)
jeden UTXO a dva nové UTXO
vytváří. Následuje hexadecimální reprezentace serializace transakce:
locktime; může udávat č. bloku, případně čas, po kterém
teprve může být tx vytěžena
4 bajty LE
Serializace této tx čítá 222 bajtů z čehož je 109 bajtů
„segwitových“ (marker, flag, witness). Pro výpočet
váhy tx vynásobíme počet
bajtů „nesegwitových“ dat čtyřmi a výsledek přičteme k
počtu segwitových bajtů (113 × 4 = 452; 452 +
109 = 561 WU). Když poté vydělíme WU čtyřmi, dostaneme tzv.
virtuální velikost (561
÷ 4 = 140,25 vB).
Odečtením součtu částek výstupů od součtu částek vstupů (hodnoty
částek vstupů nejsou součástí dat této tx; je potřeba se podívat
do předchozích) zjistíme absolutní hodnotu
poplatku (9566387 −
(9545393 + 20000) = 994). Relativní hodnoty poplatků pak
zjistíme už prostým dělením velikostí, resp. virtuální velikostí (994
÷ 222 = 4,5 satů/bajt; 994 ÷ 140 =
7,1 satů/vBajt).
Diagram popisované transakce včetně předcházející
Anatomie skriptu
Prostřednictvím skriptovacího jazyka Bitcoinu, který je záměrně co
možná nejjednodušší (a turingovsky neúplný) stanovujeme a následně i
vyhodnocujeme podmínky utracení každého UTXO. V našem případě útraty
druhého výstupu (počítáno od nuly je to výstup číslo jedna) předchozí
transakce 61149…17 musela „naše“ transakce dodat
takový podpisový skript (scriptSig), který bude vyhodnocen v kombinaci
s uzamykacím skriptem (scriptPubKey) utráceného výstupu jako pravdivý.
Skriptovací jazyk Bitcoinu pracuje se zásobníkem a samotný skript je
složen z operátoru a elementů (dat).
Než zjistíme, jakým způsobem došlo k vyhodnocení skriptů naší
rozpitvané segwitové (je utráceno segwitové UTXO) transakce, podíváme
se na to, jak tuto transakci vidí předsegwitové uzly. Takový starý
uzel vezme scriptPubKey odkazovaného výstupu předešle tx
(61149…17:1):
Před tento uzamykací skript (scriptPubKey) předešlé tx je vložen
podpisový skript (scriptSig) aktuální tx. ScriptSig naší transakce je
ale prázdný! No to nevadí, uzel začne s tím to co má. OP_0 vloží na
vrch zásobníku nulu, OP_PUSHBYTES_20 vloží na vrch zásobníku
následujících 32 bajtů skriptu. Uzel vykonal celý skript a na vrchu
zásobníku má nenulovou hodnotu (hash veřejného klíče). Skript je
pravdivý, transakce je platná. I bez podpisu je platná!
Není to
chyba, je to schválně – předsegwitové uzly neví, že podpisový
skript je nyní v poli witness, proto je zajištěno, že se těmto uzlům
bude kombinace segwitového uzamykacího skriptu a prázdného podpisového
skriptu segwit transakce jevit jako platná. Taky se tomu říká zpětná
kompatibilita.
Jak si s vyhodnocením skriptů poradí segwitový uzel? Začátek je
stejný, sáhne si do předchozí transakce pro uzamykací skript. Rozpozná
strukturu skriptu (p2wpkh) a uplatní speciální pravidlo, které skript
modifikuje do podoby:
Konečně máme skript, který nebude platný s i prázdným podpisovým
skriptem! Toto je již mimochodem struktura shodná s předsegwitovým
p2pkh. Zkušebně si vyhodnotíme tento skript bez podpisu: OP_DUP
duplikuje element na vrchu zásobníku. Zásobník je ale prázdný –
skript selhal. Nyní už to bez podpisu nepůjde.
Segwitový uzel ale ví, že v této transakci musí podpisový skript
hledat v poli witness. Finální odemykací skript naší transakce (resp.
jejího prvního a jediného vstupu) je tedy:
Vykonáme skript –
71 následujících bajtů (podpis) se vloží na vršek zásob.;
33 následujících bajtů (veřejný klíč) se vloží na vršek
zásob.;
element na vršku zásob. se zduplikuje;
element na vršku zásobníku se nahradí svým vlastním hashem
(RIPEMD160(SHA256)). Na zásobníku je nyní pohledem z vrchu hash (adresa), veřejný klíč a
podpis; dále se
20 následujících bajtů vloží na vršek zásob.
(tj. adresa z uzamykacího skriptu);
dva vrchní elementy se odeberou ze zásob. a porovnají se –
jsou‐li shodné, skript pokračuje, v opačném případě končí
chybou;
konečně poslední operátor odebere z vrchu zásob. nejprve veřejný
klíč a pak i podpis – zkontroluje podpis proti danému klíči a
předobrazu podepisované transakce a vrátí na vrch zásobníku 1 pro
platný, 0 pro neplatný podpis. Jsme na konci skriptu a je‐li na vrchu zásobníku 1,
transakce je platná.
Bonus: Předobraz transakce pro podpis
V
anatomii podpisu
se dočtete více o ověřování podpisu. Zde na tomto místě však využijeme
výše rozebranou transakci, resp. její předchůdkyni a podíváme se,
jakým způsobem vznikl její podepisovaný předobraz.
Před segwitem vznikal předobraz tak, že v případě ověření nejprve
došlo k vyprázdnění všech scriptSigů (v případě podpisu není co
vyprazdňovat, scriptSig ještě nebyl naplněn). Následně jsou tato
prázdná místa – vždy po jednom pro každý podpis – vyplněna
skripty scriptPubKey utrácených výstupů. Pro ty je potřeba sáhnout do
předchozí(ch) transakce/í. Nakonec jen přidán hashtyp – typicky
SIGHASH_ALL (číslo 1 v čtyřbajtovém LE).
Tento přístup má však dvě hlavní nevýhody. Zaprvé – výpočetní
náročnost hashování roste kvadraticky s počtem vstupů podepisované
transakce. A zadruhé – předobraz v sobě neobsahuje informaci o
částce utrácených vstupů, ze kterých by kupříkladu hardwarová
peněženka dokázala bez dalších informací vypočíst a zobrazit částku
poplatku k potvrzení. Proto byl u v rámci segwitu – konkrétně
BIPem 143
– zaveden nový způsob výroby předobrazu pro segwitové transakce.
Předobraz výše rozebrané tranasakce bude tedy vypadat následovně
(užité hashe jsou vždy dvojité SHA256):
verze tx (4 bajty LE)
hash všech txid a indexů utracených výstupů; společný pro
všechny podpisy (32 bajtů)
hash všech sequence útracených výstupů; společný pro všechny
podpisy (32 bajtů)
txid a index utráceného (podepisovaného) výstupu (32 + 4 bajty LE)
výše uvedený modifikovaný uzamykací skript utráceného
(podepisovaného) výstupu (script)
Není to
chyba, je to schválně – předsegwitové uzly neví, že podpisový
skript je nyní v poli witness, proto je zajištěno, že se těmto uzlům
bude kombinace segwitového uzamykacího skriptu a prázdného podpisového
skriptu segwit transakce jevit jako platná. Taky se tomu říká zpětná
kompatibilita.