Bitcoinový slovník naučný

Dne 12/06/2021 byl vytěžen blok s pořadovým číslem 687284, který byl 1815. blokem dané epochy obtížnosti signalizující připravenost na Taproot. Tím se bitcoinová síť dohodla na tom, že počínaje blokem 709632 (vytěžen 14/11/2021) došlo k aktivaci soft‐forku nazvaného Taproot.

Toto vylepšení přináší nový typ výstupu pay‐to‐taproot (p2tp). Ten je podobný prapůvodnímu p2pk, jelikož neuzamyká výstup ve prospěch nějakého hashe (ať už veřejného klíče – p2(w)pkh, nebo skriptu – p2(w)sh), nýbrž ve prospěch přímo agregovaného veřejného klíče. Tím se sice připravíme o jednu vrstvu ochrany před velmi hypotetickým útokem přímo na problém diskrétního logaritmu v cyklické grupě, zato ovšem ušetříme na podpisových datech, neboť již není potřeba k ověření podpisu předkládat "za hashem skrytý" veřejný klíč. Pozorný čtenář anatomie Schnorrova podpisu, kteréžto podpisové schéma bude nově pro p2tp užito, by teď měl namítnout, že sice bude ušetřeno na veřejném klíči, avšak místo dvojice 256bitových čísel (r, s) dostaneme podpis reprezentovaný bodem na křivce a 256bitovým číslem (R, s), tedy si moc nepolepšíme. Zde je však zvoleno poněkud neortodoxní řešení – nové podpisové schéma bude pracovat pouze s body, jejichž y‐ová souřadnice bude sudá. V takovém případě bude postačovat k reprezentaci bodu R pouze x‐ová souřadnice, ze které je v takovém případě y‐ová jednoznačně dopočítatelná. Podpis p2tp výstupu tedy bude v ideálním případě zabírat pouhých 64 bajtů (x‐ová souřadnice bodu R, číslo s).

Hlavním přínosem Schnorrových podpisů je však linearita tohoto schématu, díky které je možné sčítat (agregovat) jak podpisy, tak i veřejné klíče. I přesto, že patent (US4995082A) na ně vypršel už před spuštěním Bitcoinu, nebyly tehdy ještě Schrorrovy podpisy natolik využívány, proto Satoshi zvolil rozšířenější schéma ECDSA. A tak se Bitcoin jejich zavedení dočká téměř až po 13 letech v rámci Taprootu, který je na možnosti přímočarého sčítání klíčů a podpisů založen.

Tento nový výstup, označovaný také jako native segwit v1, bude používat opravenou verzi kódování adresy bech32m. U dosud používaného kódování bech32 pro native segwit v0 (p2wpkh a p2wsh) byl totiž objeven nečekaný bug – pokud bylo posledním znakem adresy písmeno p, smazaní nebo naopak přidání písmena q před tohle poslední p nemá za následek zneplatnění kontrolního součtu. Toto je tedy zavedením bech32m opraveno, ačkoliv popsaný bug neohrožuje dosavadní native segwit v0 adresy, neboť jim je BIPem 173 stanovena fixní délka.

Samotný Taproot je pak nadstavba vylepšení MAST. Jak napovídá název, toto vylepšení rozdělí skript na několik různých podmínek (alternativ) skriptu a nad těmi sestaví náš starý známý Merkleho strom hashů. Pokud má k odemčení výstupu postačovat splnění pouze některých podmínek z více stanovených, není díku MASTu potřeba odhalovat a zatěžovat blockchain těmi nesplněnými, ty budou v odemykacím skriptu reprezentovány pouze svými hashi, resp. hashi celých větví. Díky Taprootu však navíc můžeme vybrat preferovaný způsob odemčení skriptu, kupříkladu multisig 2 ze 2, který díky Schnorrovi agregujeme do jediného veřejného klíče (říkejme mu vnitřní klíč). Případné ostatní způsoby odemčení – např. opatřené spoustou různých podmínek, či časových zámků při poskytnutí pouze jednoho podpisu – budou i nadále tvořit Merkleho strom, jehož kořenový hash bude zkombinován s vnitřním klíčem, výsledkem čehož je finální veřejný klíč celého p2tp výstupu. Je‐li výstup odemčen (agregovaným) podpisem odpovídajícímu vnitřnímu klíči, není možné poznat, zda byl odemykaný výstup uzamčen jednomu, či více veřejným klíčům, ani zda existoval alternativní způsob odemčení skriptem. V případě odemčení skriptem je pak i nadále nutné vyjevit pouze ty splňované podmínky.

Co prozatím Taproot nepřináší, je možnost vytvoření jednoho agregovaného podpisu pro několik různých vstupů (cross‐input signature aggregation). I nadále platí, že každý vstup transakce musí mít svůj vlastní podpis.