Miniscript

Anna chce mít běžný přístup ke svým mincím pomocí vlastního klíče. Digitální podpis dokládá oprávnění k platbě pomocí soukromého klíče, tajného číselného údaje, aniž by jej odhalil. Peněženka je aplikace nebo zařízení pro přijímání a odesílání bitcoinů. Anna zároveň chce připravit cestu pro Petra, který je bude moci utratit svým klíčem po 144 blocích od potvrzení daného výstupu. Takový záměr se označuje jako spending policy, tedy pravidla utrácení. Miniscript pomáhá převést záměr do přesné podoby, se kterou umí pracovat peněženka. Petr stále potřebuje svůj klíč; čekání ho nenahradí. Jde o jednoduchý příklad dvou přístupových cest, nikoli o automatický převod nebo rozpoznání, že Anna ztratila klíč. [1] [2] [10]

Pravidlo vyslovené větou ještě není program, který síť ověří. Překladač může ze záměru zvolit konkrétní Miniscript a převést jej do Bitcoin Scriptu. Output Descriptor pak popisuje výsledné skripty společně s klíči a případnými postupy jejich odvození; může nést i kontrolní součet proti chybám při opisu. Síť při utrácení kontroluje skutečný skript a předložená data, ne původní českou větu. Miniscript nepřidává novou instrukci ani nemění konsenzus, tedy společná pravidla platnosti. Neumí vyjádřit každý myslitelný Bitcoin Script. [1] [3] [6]

Blok sdružuje transakce do dávky, která se připojuje ke společné historii. V příkladu s Petrem se 144 bloků počítá od potvrzení výstupu, konkrétní částky se stanovenými podmínkami. Není to přesně odměřený den ani doba od vytvoření peněženky. Miniscript zapisuje relativní podmínku jako older(n); opírá se o CSV a pole nSequence příslušného vstupu utrácející transakce. Význam tohoto pole při ověřování stáří určuje BIP 68. Naproti tomu after(n) používá CLTV a absolutní nLockTime, tedy pevnou výšku nebo časovou hranici. Peněženka musí správně nastavit transakční pole i ostatní podmínky. Výškové a časové zámky nelze spojovat nekompatibilně; uplynutí čekání samo nic neodešle. [1] [7] [8] [9] [11]

K utracení nestačí ukázat popis pravidel. Peněženka musí dodat data, která některou povolenou cestu splní: například podpisy, případně tajemství odpovídající požadovanému hashi, tedy jeho preimage. Hash je digitální otisk dat; zde se ověřuje, zda předložené tajemství vytvoří právě požadovaný otisk. Takové splnění se nazývá satisfaction; potřebná vstupní data tvoří součást witnessu transakce. Při skládání větví může být nutné určitou dílčí podmínku nechat podle pravidel vyhodnotit jako nepravdivou, aby se použila jiná. Tomu se říká dissatisfaction a neznamená to neplatnost celé platby. Software může vhodnou cestu sestavit, ale nevymyslí chybějící soukromý klíč ani neznámé tajemství. [1] [12]

PSBT je formát, který předává připravenou transakci a doplňující údaje mezi peněženkou a zařízeními, jež ji podepisují. Samotná podpora PSBT však nestačí: program i Hardware Wallet musí rozumět použitému descriptoru a jeho podmínkám. Bitcoin Core přidal ve verzi 24 podporu sledování Miniscriptu v P2WSH, ve verzi 25 podepisování a ve verzi 26 použití v Taproot descriptorech. Sledovat mince tedy není totéž jako umět je utratit. Při nastavení ověřte na důvěryhodném displeji klíče, požadované podpisy, čekání a všechny alternativní cesty podle možností konkrétního zařízení. [3] [4] [5]

Seed Phrase obnovuje klíče, ale u vlastní složité podmínky nemusí sama prozradit, jak byly spojeny s ostatními klíči a skriptem. Jde o zálohu zapsanou jako posloupnost slov, z níž peněženka dokáže odvodit své klíče. Uchovejte přesný descriptor s kontrolním součtem, mapu použitých klíčů, jejich odvozovací cesty a rozlišení adres pro příjem a vracení zbytku. Zvlášť zaznamenejte síť, rozsah adres a počátek prohledávání historie. Veřejný descriptor není soukromý klíč, ale může odhalit platební historii. Než takové uspořádání použijete, vyzkoušejte obnovení sledovací peněženky i každou zamýšlenou cestu utracení v testovacím prostředí Regtest nebo Signet. [5] [6]

Zápisy pk(), older(), after() a sha256() představují podpis, čekání nebo požadavek na tajemství. Výrazy and_v(), or_d() a thresh() umožňují podmínky skládat. Obaly jako v: upravují způsob vyhodnocení při zachování významu podvýrazu. Typy B, V, K a W hlídají, jak si části předávají položky na zásobníku, pracovní ploše skriptu; ne každé dvě části se k sobě hodí. Typová kontrola tak odhalí neslučitelnou skladbu. Nerozhodne ale za Annu, komu má věřit ani zda si vybrala rozumnou záložní cestu. [1] [2]

Struktura umožňuje předem analyzovat velikost skriptu i witnessu, počet operací, podpisových kontrol a položek zásobníku. To pomáhá odhadnout náklady různých cest a odhalit překročení povolených mezí. Záleží však na prostředí: P2WSH ukládá podmínky v rámci SegWitu, zatímco Tapscript označuje skripty používané v Taproot. Jejich limity nejsou ve všem shodné. Kromě konsenzuálních pravidel se uplatňují i pravidla běžného přenosu transakcí. Výsledek analýzy tedy není univerzální potvrzení, že každá peněženka připravený postup zvládne. [1]

Veřejný klíč slouží k ověřování podpisů a nemusí se držet v tajnosti. Analýza malleability zkoumá, zda cizí člověk může z jedné platné satisfaction udělat jinou, stále platnou. Příslušné záruky mají konkrétní předpoklady: útočník nemá účastnické soukromé klíče, nezná více preimages než poctivý uživatel a vidí jen jedno splnění. Uvažují se také neopakované veřejné klíče a běžná pravidla přijímání; těžař může mít jiné možnosti než běžný přeposílající uzel. Nejde proto o záruku proti všem škodlivým účastníkům, ztrátě záloh nebo chybnému návrhu úschovy. Tyto otázky je nutné řešit zvlášť. [1]

Překladač může stejná pravidla vyjádřit více způsoby s různou velikostí skriptu a witnessu. Volí podle nákladového modelu. Značka 9@ u větve v jazyce pro zápis pravidel utrácení je nápověda o relativní pravděpodobnosti jejího použití, ne počet podpisů ani síťové oprávnění. Jiný způsob překladu může vytvořit jiný skript a tím i jiné adresy. Při obnově proto nestačí pravidla znovu popsat vlastními slovy a znovu je převést do skriptu. Důležitá je přesná uložená podoba, kontrola odvozených adres a ověřená cesta podpisu. [2] [5]