PSBT v2

Anna a Jan chtějí společně zaplatit jednu fakturu. Každý použije část svých prostředků a svůj podpis přidá na vlastním zařízení. Potřebují si předat shodný návrh, nikoli své soukromé klíče. Soukromý klíč je tajné číslo, kterým peněženka vytváří digitální podpis pro schválení utracení. K předávání návrhu slouží PSBT, pracovní obálka s transakcí a podklady. Vstupy určují dřívější částky, které se utrácejí; výstupy určují nové částky a podmínky jejich dalšího utracení. Původní PSBT v0 má tuto kostru pevně uloženou v globální nepodepsané transakci. Ve v2 lze vstupy a výstupy za příslušných pravidel doplňovat postupně. Výhodou je společné sestavování, nikoli možnost libovolně přepisovat to, co už někdo podepsal. [1] [2]

Anna nemusí číst jednotlivá technická pole. Na důvěryhodném podepisujícím zařízení však potřebuje ověřit skutečného příjemce, částku, poplatek a případné vrácení zbytku do vlastní peněženky. Právě poslední položka bývá méně nápadná: nesmí zaměnit cizí výstup za vlastní vrácené peníze. Zařízení musí zkontrolovat podklady UTXO, tedy dosud neutracených výstupů, a soulad jejich podmínek s tím, co podepisuje. Cesta odvození klíče popisuje kroky, kterými peněženka z hlavního klíče získá konkrétní klíč. Údaj o cestě ke klíči sám o sobě vlastnictví nedokazuje. Podepisující zařízení musí také správně vyhodnotit SIGHASH, nastavení určující, které části transakce podpis chrání. Do předávaného souboru se kvůli podpisu nemá přidávat soukromý klíč ani Seed Phrase, záložní sada slov k peněžence. [2] [4]

Podpora PSBT na krabičce nebo v aplikaci ještě neříká, že si poradí právě s v2. Ověřit je potřeba celý postup: vytvoření, import, podpis i vrácení výsledku mezi konkrétními programy a zařízeními. PSBT v0 a v2 nejsou přímo zaměnitelné. Převod do v0 vyžaduje sestavit nepodepsanou transakci a upravit pole podle pravidel dané verze; nestačí změnit číslo. Ani Taproot, novější způsob stanovení podmínek bitcoinových výstupů, není totéž co v2. Jeho podklady pro podpis popisuje BIP 371 pro obě verze PSBT. Malá zkouška celé cesty ověří kompatibilitu dané sestavy, nikoli správnost všech příštích plateb. [1] [3]

Číslo verze souborového formátu a číslo verze bitcoinové transakce mají jiný význam. Ve v2 musí PSBT_GLOBAL_VERSION obsahovat 2, zatímco staré pole PSBT_GLOBAL_UNSIGNED_TX musí chybět. Samostatné povinné PSBT_GLOBAL_TX_VERSION určuje verzi samotné transakce. Povinné jsou i počty vstupů a výstupů. Díky tomuto rozdělení lze jejich údaje uložit rovnou k jednotlivým položkám, místo aby je program hledal i v jedné společné kostře. Jestliže tvůrce předá doplňování jiným účastníkům, musí podle BIP 370 nastavit příslušné příznaky změn a verzi transakce alespoň na 2. V každém případě jde o pracovní formát, nikoli nová konsenzuální pravidla sítě. [1]

Každý vstup potřebuje TXID, identifikátor předchozí transakce, a index konkrétního výstupu, který se z ní utrácí. Samotné TXID nestačí: transakce může mít více výstupů. Každý nový výstup nese částku v satoshi, nejmenších jednotkách Bitcoinu, a scriptPubKey, skript s podmínkami utracení. Přidání položky musí odpovídat i změna jejího globálního počtu. Volitelné pole sequence nese další řídicí údaj vstupu; pokud chybí, použije se 0xffffffff. Všechny tyto konstrukční údaje říkají, jak transakci sestavit. Nenahrazují ale podklady o hodnotě a podmínkách utrácených UTXO, bez kterých by zařízení nemohlo bezpečně vyhodnotit podpis a poplatek. [1]

Představme si, že Jan potřebuje přidat další vstup. Program nesmí předpokládat, že to jde jen proto, že má soubor k dispozici. V PSBT_GLOBAL_TX_MODIFIABLE bit 0 označuje možnost změn vstupů a bit 1 možnost změn výstupů. Bit 2 upozorňuje na podpis SIGHASH_SINGLE, který váže vstup k výstupu na odpovídající pozici. Toto párování je nutné zachovat i při vkládání dalších položek. Sestavovatel proto prochází konkrétní podpisy a jejich omezení. Příznaky jsou informace pro spolupracující programy; neobejdou kryptografický podpis a samy neudělají neplatnou změnu platnou. [1]

Některé vstupy požadují, aby transakce nebyla použitelná dříve než po určité výšce bloku nebo časové hranici. Blok je skupina transakcí zapsaná do společné historie sítě; jeho výška udává jeho pořadí v řetězci. Společné pole nLockTime musí odpovídat slučitelnému typu požadavků všech vstupů. Z vybraného typu se vezme nejvyšší požadovaná hodnota; jsou-li možné oba typy, přednost dostane výška bloku. Výšku a čas tedy nelze prostě porovnat jako dvě obyčejná čísla. Pokud žádný vstup požadavek nemá, použije se globální náhradní hodnota, případně 0. Nový vstup s neslučitelným požadavkem se nepřidá. Pokud už existují podpisy, nový vstup navíc nesmí změnit vypočtené nLockTime. Tato pole sama nezajišťují, že transakce splní všechna pravidla časových zámků. [1]

Podpis postupně omezuje další úpravy. BIP 370 požaduje, aby podepisující bez SIGHASH_ANYONECANPAY vypnul změny vstupů a bez SIGHASH_NONE vypnul změny výstupů; u SIGHASH_SINGLE zaznamená nutné párování. Tyto názvy označují různé rozsahy ochrany podpisem, nikoli volby, které má začátečník náhodně přepínat. Až jsou všechny vstupy připravené, finalizace sestaví potřebná podpisová data a extraktor z polí vytvoří transakci ve formátu pro síť. Teprve její odeslání umožní uzlům ji posoudit a těžaři ji zařadit do bloku. Anna s Janem tedy rozlišují připravený návrh, podepsaný výsledek a potvrzenou platbu; pouhé předání PSBT ještě není ani jedno z posledních dvou. [1] [2] [4]