FROST znamená Flexible Round-Optimized Schnorr Threshold. Jde o prahový podpisový protokol, v němž dostatečný počet účastníků podepisuje společným veřejným klíčem, aniž by při podpisu skládali celý tajný klíč na jednom místě.
U schématu 2 ze 3 stačí dva dostupné oprávněné podíly, zatímco jeden k vytvoření podpisu nestačí. Získá-li útočník dva, může práh splnit také. Podíl dlouhodobého klíče není částečný podpis konkrétní zprávy; podpis vzniká až společným protokolem s čerstvými jednorázovými hodnotami. [RFC 9591 — FROST]
Důvěryhodný distributor může vytvořit tajemství a rozdělit podíly, takže zná celý klíč a musí s ním bezpečně naložit. DKG umožňuje společné vytvoření bez takového jediného distributora, ale přidává vlastní komunikaci a ověřování. RFC 9591 vymezuje hlavně podpis; příloha s distributorem neznamená, že každé nasazení automaticky používá DKG. [RFC 9591 — FROST] [ZF FROST Book — key generation and recovery]
V prvním kole účastník vytvoří dvě tajné nonce a sdílí jejich veřejné závazky. Ve druhém ověří zprávu, seznam účastníků a vlastní závazky a vypočte svou část podpisu. Koordinátor části spojí. Vazební faktory propojují nonce s konkrétní zprávou a sadou závazků; dvě kola nepočítají předchozí tvorbu klíčů. [RFC 9591 — FROST] [ZF frost-secp256k1-tr — Taproot implementation]
Opakované použití nonce může umožnit odhalení tajného klíčového materiálu. Po použití je nutné bezpečně vyřadit tajné nonce i při přerušeném pokusu; obnova staré zálohy nesmí obnovit jejich použitelnost. Náhodnost, souběžné relace a trvalé sledování spotřeby jsou součástí bezpečnosti, ne pouhou optimalizací rychlosti. [RFC 9591 — FROST]
Koordinátor sbírá závazky a části podpisu; bez dostatečných podílů nemá oprávnění podepsat sám. Může ovšem zadržet zprávy nebo způsobit přerušení. Kontrola vadné části může odhalit jejího původce, nikoli zajistit dokončení relace. Autentizovaný přenos a dostatek dostupných účastníků zůstávají nutné. [RFC 9591 — FROST]
Pro Bitcoin musí výsledek vyhovět přesnému formátu, hashování a pravidlům BIP 340 a případným Taproot úpravám klíče. Samotná volba secp256k1 v obecné sadě FROST nestačí. Implementace ZF odděluje frost-secp256k1-tr pro Taproot; ověř konkrétní sadu a její testy. Jediný podpis na řetězci sám neprozrazuje interní práh. [ZF frost-secp256k1-tr — Taproot implementation] [BIP 340 — Schnorr Signatures for secp256k1]
Podíl potřebuje správný identifikátor, skupinové veřejné údaje a kompatibilní software. Obnova ztraceného podílu pomocí ostatních nebo obměna podílů jsou další protokoly, které musí nasazení skutečně podporovat. Kopie téhož podílu nepřidává nezávislého účastníka. Plán záloh musí současně zachovat práh a zabránit návratu již spotřebovaných nonce. [ZF FROST Book — key generation and recovery] [ZF frost-secp256k1-tr — Taproot implementation]
Každý podepisující má zkontrolovat příjemce, částky, poplatek a schvalovací pravidla, nikoli slepě podepsat hash dodaný koordinátorem. FROST řeší společné vytvoření podpisu, ne správnost obchodního záměru. Před použitím ověř konkrétní verzi implementace, postup obnovy a chování při výpadku; informační RFC není osvědčením celé peněženky. [RFC 9591 — FROST]
Pro nejúplnější obraz čtěte toto heslo společně s Schnorrův podpis, MuSig2, Multisig, Taproot, Shamir Secret Sharing.