FROST steht für Flexible Round-Optimized Schnorr Threshold. Bei diesem Schwellwertprotokoll signieren genügend Beteiligte unter einem gemeinsamen öffentlichen Schlüssel, ohne beim Signieren den gesamten geheimen Schlüssel an einem Ort zusammenzusetzen.
Bei 2 von 3 genügen zwei verfügbare berechtigte Anteile; einer kann keine Signatur erzeugen. Erlangt ein Angreifer zwei, erfüllt auch er den Schwellwert. Ein langfristiger Schlüsselanteil ist keine Teilsignatur einer bestimmten Nachricht: Zum Signieren braucht es das gemeinsame Protokoll mit frischen Einmalwerten. [RFC 9591 — FROST]
Ein vertrauenswürdiger Verteiler kann das Geheimnis erzeugen und Anteile verteilen; er kennt somit den ganzen Schlüssel und muss sicher damit umgehen. DKG erlaubt eine gemeinsame Erzeugung ohne diesen einzelnen Verteiler, benötigt aber eigene Kommunikation und Prüfungen. RFC 9591 beschreibt vor allem das Signieren; sein Verteiler-Anhang bedeutet nicht, dass jede Anwendung automatisch DKG nutzt. [RFC 9591 — FROST] [ZF FROST Book — key generation and recovery]
In Runde eins erzeugt ein Teilnehmer zwei geheime Nonces und teilt deren öffentliche Bindungen. In Runde zwei prüft er Nachricht, Teilnehmerliste und eigene Bindungen und berechnet seinen Signaturanteil. Ein Koordinator aggregiert die Anteile. Bindungsfaktoren verknüpfen Nonces mit der konkreten Nachricht und Bindungsmenge; die vorherige Schlüsselerzeugung zählt nicht zu den zwei Runden. [RFC 9591 — FROST] [ZF frost-secp256k1-tr — Taproot implementation]
Nonce-Wiederverwendung kann geheimes Schlüsselmaterial offenlegen. Nach Gebrauch müssen geheime Nonces sicher ausgemustert werden, auch bei abgebrochenen Versuchen; ein altes Backup darf sie nicht wieder verwendbar machen. Zufälligkeit, gleichzeitige Sitzungen und dauerhaftes Erfassen des Verbrauchs gehören zur Sicherheit, nicht nur zur Geschwindigkeitsoptimierung. [RFC 9591 — FROST]
Der Koordinator sammelt Bindungen und Signaturanteile; ohne genügend Schlüsselanteile hat er keine Befugnis, allein zu signieren. Er kann jedoch Nachrichten zurückhalten oder einen Abbruch verursachen. Die Prüfung eines fehlerhaften Anteils kann dessen Urheber identifizieren, garantiert aber keinen Sitzungsabschluss. Authentisierte Übertragung und genügend verfügbare Teilnehmer bleiben nötig. [RFC 9591 — FROST]
Für Bitcoin muss das Ergebnis die genaue Kodierung, Hashbildung und Regeln von BIP 340 sowie etwaige Taproot-Schlüsselanpassungen erfüllen. secp256k1 in einer allgemeinen FROST-Suite allein genügt nicht. ZF bietet separat frost-secp256k1-tr für Taproot; prüfe die konkrete Suite und ihre Tests. Eine einzelne On-Chain-Signatur verrät für sich nicht den internen Schwellwert. [ZF frost-secp256k1-tr — Taproot implementation] [BIP 340 — Schnorr Signatures for secp256k1]
Ein Anteil benötigt die richtige Kennung, öffentliche Gruppendaten und kompatible Software. Einen verlorenen Anteil mithilfe anderer wiederherzustellen oder Anteile zu erneuern sind zusätzliche Protokolle, die die Anwendung tatsächlich unterstützen muss. Eine Kopie desselben Anteils fügt keinen unabhängigen Teilnehmer hinzu. Backups müssen den Schwellwert erhalten und zugleich verhindern, dass verbrauchte Nonces zurückkehren. [ZF FROST Book — key generation and recovery] [ZF frost-secp256k1-tr — Taproot implementation]
Jeder Signierende sollte Empfänger, Beträge, Gebühren und Freigaberegeln prüfen, statt blind einen Hash des Koordinators zu signieren. FROST ermöglicht gemeinsames Signieren, nicht die Richtigkeit der geschäftlichen Absicht. Prüfe vor Nutzung Implementierungsversion, Wiederherstellung und Ausfallverhalten; ein informatives RFC zertifiziert nicht die gesamte Wallet. [RFC 9591 — FROST]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Schnorr-Signatur, MuSig2, Multisig, Taproot, Shamir Secret Sharing.