Bitcoin Script

Alice přijme 20 000 sat, tedy dvacet tisíc nejmenších jednotek bitcoinu. V síti nevznikne účet s jejím jménem, ale výstup transakce: částka a podmínka jejího dalšího utracení. Než se utratí, říká se mu UTXO. V běžném případě podmínka vyžaduje podpis odpovídajícím klíčem. Alicina peněženka si proto při pozdější platbě vybere tento výstup, odkáže na něj novým vstupem transakce a vytvoří digitální podpis. K tomu použije soukromý klíč, který nikam neposílá; ostatní ověří podpis pomocí veřejného klíče. Znalost Aliciny přijímací adresy nestačí. Podmínky původního výstupu jsou zapsané v poli scriptPubKey a Bitcoin Script určuje, jak se jejich splnění ověřuje. Uzel přitom není úředník, který pozná Alici: je to počítač kontrolující pravidla. Vedle podpisu musí ověřit také například to, že stejný výstup nebyl už utracen. Teprve splnění všech příslušných pravidel dělá transakci platnou. [4] [2]

Při obyčejném placení sestavuje podmínky peněženka. Zálohujte ji podle jejího návodu; běžná kompatibilní obnova ze slov automaticky nevyžaduje ručně ukládat každý skript. U složitějšího uspořádání, třeba Multisig vyžadujícího více podpisů, ale samotná slova jednoho účastníka nemusí popisovat celý postup utracení. Pro běžné použití je vhodná peněženka s ověřenými postupy místo ručního sestavování skriptů v šestnáctkovém zápisu. Deskriptory výstupů popisují typ skriptu, klíče a jejich odvozování; pomáhají tak určit, co má obnovená peněženka hledat. Samotný soukromý klíč nemusí stačit k obnovení složitějšího uspořádání. Uchovejte také potřebné skripty a údaje o původu klíčů, tedy odkud a jak byly odvozeny, a ověřte zamýšlené cesty útraty. [11]

Následující kapitoly ukazují zápis podmínek uvnitř transakce; k běžnému placení ho znát nemusíte. Pole scriptSig a část zvaná witness předávají údaje k ověření. Hash je otisk dat a časový zámek zakazuje útratu před určitou hranicí. Zásobník si lze představit jako hromádku položek, s nimiž se pracuje shora. Script zpracovává data pomocí zásobníku: hodnoty na něj vkládá a instrukce zvané opkódy je odebírají, porovnávají nebo jinak zpracovávají. Podpisové instrukce podpisy ověřují; soukromé klíče ani vytváření podpisů do tohoto ověřování nepatří. Jazyk umožňuje kombinovat podpisy, hashové podmínky a časové zámky. Nemá obecné cykly a není turingovsky úplný: nelze v něm vyjádřit libovolný výpočet jako v univerzálním programovacím jazyce. Uzel musí použít přesná pravidla odpovídající danému typu výstupu a verzi skriptu. [1] [3]

U P2PKH (Pay to Public Key Hash) má výstup obvyklý tvar OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. Vstup ve svém scriptSig poskytne podpis a veřejný klíč. Ověření zkontroluje, zda hash veřejného klíče odpovídá hodnotě ve výstupu, a následně ověří podpis. Samotná znalost adresy nebo veřejného klíče proto k takové útratě nestačí. Soukromý klíč používá podepisující peněženka, nikoli uzel, který transakci kontroluje. [1]

P2SH podle BIP16 ukládá do výstupu hash skriptu. Utrácející vstup poskytne odpovídající redeemScript, tedy skript odhalený při útratě, spolu s potřebnými daty. Jeho scriptSig smí obsahovat pouze instrukce vkládající data. Uzel nejprve zkontroluje shodu hashe a potom vyhodnotí redeemScript se zbývajícími položkami zásobníku. Správný hash sám o sobě k útratě nestačí: musí být splněny i podmínky tohoto skriptu. [5]

U SegWit verze 0 se údaje pro ověření přesouvají do části transakce označované witness. Ta je seznamem datových položek, nikoli sama o sobě skriptem. P2WPKH používá podpis a veřejný klíč; P2WSH obsahuje také witnessScript, jehož hash SHA256 musí odpovídat výstupu. U nativního SegWit je scriptSig prázdný. Při zabalení do P2SH obsahuje pouze vložení příslušného programu witness; vlastní ověřovací data zůstávají ve witness. [6]

Ověření podpisu pracuje se zprávou odvozenou z transakce podle stanoveného postupu. Režim SIGHASH určuje, které její části podpis chrání proti změně. Nelze proto automaticky tvrdit, že každý podpis pokrývá úplně celou transakci. BIP143 pro podpisové operace v SegWit verze 0 zahrnuje vždy i částku utráceného výstupu. Peněženka musí znát správné údaje a zvolený režim; Script při kontrole neposuzuje lidský záměr podepisujícího. [7]

Taproot podle BIP341 umožňuje utratit výstup P2TR (Pay to Taproot) dvěma způsoby. Cesta přes klíč ověřuje Schnorrův podpis vůči výstupnímu veřejnému klíči, aniž odhalí skript. Cesta přes skript naopak odhalí vybraný skript a řídicí blok, označovaný control block, který prokáže jeho vazbu k výstupu. Ostatní skripty ve stromu se odhalovat nemusí. Pravidla pro odhalený skript závisejí také na verzi příslušného listu. [8]

BIP342 definuje Tapscript pro listy Taprootu verze 0xc0. Podpisové instrukce zde používají Schnorrovy podpisy a OP_CHECKSIGADD umožňuje sestavit podmínku vyžadující více podpisů. Staré OP_CHECKMULTISIG je při vykonání zakázané. Nepřebírá se dřívější limit délky skriptu 10 000 bajtů ani limit 201 opkódů počítaných podle starších pravidel. Počet podpisových operací omezuje rozpočet odvozený od velikosti witness; nadále existují limity zásobníku. Limity jedné verze se proto nesmějí vydávat za obecné vlastnosti celého Scriptu. [9]

Pravidla konsenzu určují platnost útraty v bloku. Standardnost označuje další místní pravidla uzlu pro přijímání nepotvrzených transakcí do Mempoolu a jejich šíření; není to proces standardizace. Konsenzuálně platná transakce proto nemusí být běžně šířena. Zvláštní pozornost vyžaduje OP_SUCCESSx v Tapscriptu: po úspěšných předchozích kontrolách jeho rozpoznání při dekódování ukončí ověření skriptu úspěchem ještě před běžným vykonáváním a kontrolami zásobníku. Jde o prostor pro budoucí rozšíření, nikoli běžnou bezpečnou podmínku útraty. [10] [9]