Mit MuSig2 können mehrere Personen gemeinsam eine Schnorr-Signatur erzeugen. Sie belegt die Zustimmung zu einer bestimmten Nachricht, ohne ihre privaten Schlüssel offenzulegen. Das Verfahren nach BIP327 nutzt zwei Kommunikationsrunden. Öffentliche Schlüssel werden zu einem gemeinsamen Schlüssel und Signaturbeiträge zu einer BIP340-kompatiblen Signatur zusammengeführt. Das Grundmodell ist n-of-n: Jeder beteiligte Unterzeichner muss beitragen.
Stellen Sie sich eine gemeinsame Kasse vor, bei der Alice und Bob jede Zahlung freigeben müssen. Eine digitale Signatur weist die Berechtigung zur Zahlung nach. Sie wird mit einem privaten Schlüssel erzeugt, also einem geheimen Zahlenwert, der dabei nicht offengelegt wird. Ein herkömmlicher skriptbasierter Multisig kann mehrere Schlüssel und Signaturen in der Transaktion offenlegen. Mit MuSig2 behält jeder seinen privaten Schlüssel und trägt zur gemeinsamen Signatur bei. Das Netzwerk prüft ein einziges Ergebnis. Gespart wird bei Speicherung und Prüfung auf der Blockchain; die Abstimmung zwischen den Beteiligten bleibt nötig. Jonas Nick, Tim Ruffing und Yannick Seurin stellten das Protokoll in einer im Oktober 2020 veröffentlichten Arbeit vor. [3] [2] [10]
MuSig2 allein ist keine 2-of-3-Lösung, bei der beliebige zwei Personen einen fehlenden dritten Unterzeichner ersetzen. Bei seinem n-of-n-Modell muss jedes Gruppenmitglied beitragen. Ein unerreichbarer oder unwilliger Teilnehmer kann den Vorgang stoppen. Eine Wallet ist eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. Soll die Wallet auch dann nutzbar bleiben, braucht sie einen gesondert geplanten Ausgabepfad oder Signaturmechanismus. Der Name MuSig2 liefert diesen nicht automatisch mit. [1] [8]
Vor dem Signieren bilden die Beteiligten einen gemeinsamen öffentlichen Schlüssel. Der öffentliche Schlüssel dient zur Prüfung von Signaturen und muss nicht geheim bleiben. In der ersten Runde tauschen sie öffentliche Nonces aus, einmalige Beiträge zur Vorbereitung der Signatur. In der zweiten erzeugen und übermitteln sie Teilsignaturen für dieselbe Nachricht und denselben Kontext. Daraus entsteht die fertige Signatur. Unter den Bedingungen des Protokolls lässt sich die erste Runde vorbereiten, bevor die Zahlung feststeht. Vor dem Erzeugen seiner Teilsignatur muss jedoch jeder die konkrete Transaktion prüfen, insbesondere Empfänger, Betrag und Gebühr. Vorbereitung bedeutet keine Zustimmung zu einer unbekannten Zahlung; eine Prüfung erst nach dem Signieren kommt zu spät. [1] [3]
Bei einer naiven Summe könnte ein Angreifer seinen öffentlichen Schlüssel so wählen, dass er die Schlüssel anderer ausnutzt. MuSig2 verwendet deshalb Zahlen als Gewichtungsfaktoren, sogenannte Koeffizienten, die aus der Schlüsselliste abgeleitet werden. KeyAgg berücksichtigt auch deren Reihenfolge; für eine einheitliche Sortierung kann die Anwendung KeySort verwenden. Alle müssen dieselbe Liste und dieselben Regeln nutzen, sonst berechnen sie unterschiedliche gemeinsame Schlüssel. [1] [5]
Nonce meint hier keinen Mining-Zähler, sondern einmaliges Signaturmaterial: pubnonce wird weitergegeben, secnonce bleibt beim Unterzeichner. Eine geheime Nonce darf niemals für einen weiteren Aufruf von Sign wiederverwendet werden. Zwei dadurch entstandene Teilsignaturen können den privaten Schlüssel offenlegen. Weder eine geänderte Nachricht noch die Wiederholung einer scheinbar identischen Zahlung ist eine sichere Ausnahme. [1] [7]
Korrekte Kryptografie genügt nicht, wenn die Anwendung nach einem Neustart eine gebrauchte secnonce aus einer Sicherung lädt oder sie zwei parallelen Aufgaben übergibt. Libsecp256k1 macht die geheime Nonce beim Signieren durch Überschreiben unbrauchbar; eine Kopie außerhalb seiner Kontrolle kann den Schutz umgehen. Die Zustandsverwaltung muss Wiederverwendung auch bei Fehlern, Wiederherstellung und paralleler Verarbeitung verhindern. Der private Signaturschlüssel darf mehrfach verwendet werden; nur die Nonce ist einmalig. [7]
Ein Koordinator kann öffentliche Nonces und Teilsignaturen einsammeln und den Austausch vermitteln. Bei korrekter Protokollanwendung kann er dadurch nicht anstelle eines ehrlichen Teilnehmers signieren, wohl aber den Ablauf stören. Jeder Unterzeichner muss prüfen, was er unterschreibt. Die Prüfung von Teilsignaturen kann Fehler aufdecken, benötigt dafür aber die ursprünglichen öffentlichen Beiträge und den richtigen Kontext. Eine aggregierte Nonce allein verrät den Verursacher nicht. [1] [7]
Das Ergebnis ist eine 64-Byte-Signatur nach BIP340. Beim Taproot Key Path prüft das Netzwerk die Signatur für den im Output festgelegten Schlüssel, ohne ein Ersatzskript offenzulegen. Wird nicht der Standardmodus verwendet, folgt der Signatur ein Byte für den Sighash-Typ. Dieser bestimmt, welche Teile der Transaktion durch die Signatur gebunden sind: Änderungen daran würden die Signatur ungültig machen. Die Signatur allein verrät weder die Anzahl der Beteiligten noch ihre einzelnen Schlüssel. MuSig2 verbirgt aber keine Beträge, sämtliche Zusammenhänge der Zahlung oder die Kommunikation zwischen den Parteien. Auch Signaturen verschiedener Inputs werden nicht automatisch zusammengefasst; Inputs verweisen auf früher empfangene Outputs, die nun ausgegeben werden. [5] [6]
Neben dem gemeinsamen Key Path kann Taproot Skriptbedingungen enthalten, etwa eine andere Schlüsselkombination oder eine Zeitsperre. Eine Zeitsperre macht einen bestimmten Weg erst nach einer festgelegten Zeit oder Blockhöhe nutzbar; erforderliche Signaturen ersetzt sie nicht. Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. Die Blockhöhe bezeichnet die Position eines Blocks in der Kette. Die Bedingungen müssen bereits bei Erstellung des Outputs, eines Betrags mit Ausgaberegeln, kryptografisch festgelegt sein. Nach dem Verlust eines Unterzeichners lassen sie sich nicht nachtragen. Der Script Path ist die Ausgabe über ein solches Skript: Er legt die betreffenden Bedingungen offen und kann teurer sein. Für die Wiederherstellung braucht man daher Angaben zur gewählten Gestaltung, nicht nur die einzelnen geheimen Schlüssel. [6] [1] [9]
BIP327 beschreibt das Protokoll, während Bibliothek und Wallet die tatsächliche Schnittstelle, Sicherungen und Abläufe bestimmen. Prüfen Sie Version, Testvektoren, Nonce-Verwaltung und Transaktionskontrolle. Die Unterstützung von Schnorr-Signaturen bedeutet noch keine vollständige MuSig2-Unterstützung in jeder Wallet. Das gemeinsame Signieren nutzt bestehende BIP340- und Taproot-Regeln; MuSig2 allein benötigt keinen neuen Konsens-Opcode. [4] [7] [2]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Schnorr Signature, Taproot, Multisig, PSBT. Auf diesen Eintrag verweisen außerdem Schnorr Signature, Submarine Swap, FROST, PTLC.