Schnorr Signature

Alice möchte Bitcoin an Bob senden. Eine Wallet ist eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. Ihre Wallet erstellt eine Transaktion und signiert mit dem privaten Schlüssel die Daten, die der gewählte Signaturmodus vorgibt. Ein Knoten prüft anschließend die Signatur und alle weiteren Ausgabebedingungen. Ein Knoten ist ein Programm, das Transaktionen und Blöcke prüft und sich mit anderen Netzwerkteilnehmern austauscht. Eine gültige Signatur allein bestätigt weder Alices amtliche Identität noch die Wahl des richtigen Empfängers noch das Vorhandensein ausreichender, noch nicht ausgegebener Coins; das sind getrennte Fragen. Auch eine signierte Zahlung kann ein unbeabsichtigter Fehler sein. [5] [3] [10] [11]

BIP340 von Pieter Wuille, Jonas Nick und Tim Ruffing definiert die Schnorr-Signatur für Bitcoin genau. BIP341 bindet sie in die Taproot-Ausgaberegeln ein, die im Mainnet, dem Hauptnetzwerk von Bitcoin, bei Block 709632 im Jahr 2021 aktiviert wurden. Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. Es handelt sich um zwei Ebenen: Signaturalgorithmus und Ausgabebedingungen. Ältere Ausgänge und SegWit v0 verwenden weiterhin ECDSA, das ältere Signaturverfahren; ihre Signaturen wurden durch die Aktualisierung nicht rückwirkend ersetzt. [1] [2] [11]

Ein Byte ist eine übliche Einheit für Datenmengen. Die Bitcoin-Variante nutzt die elliptische Kurve secp256k1, eine mathematische Struktur für Schlüssel und Signaturen. BIP340 legt ein festes Signaturformat von 64 Byte fest. Der öffentliche Schlüssel wird als 32 Byte lange x-Koordinate dargestellt. x-only bedeutet nicht, dass eine Sicherheitsprüfung entfällt: Die Regeln bestimmen eindeutig, welche Variante des Kurvenpunkts der Prüfer verwendet. Ein kleineres, präzise definiertes Format hilft der Software. Die Größe einer gesamten Transaktion lässt sich aus diesen beiden Zahlen allein jedoch nicht ablesen. [1] [12]

Eine Wallet signiert kein unbestimmtes „Ich stimme zu“. Der Sighash-Modus legt fest, aus welchen Transaktionsdaten die signierte Nachricht entsteht. SIGHASH_DEFAULT schützt Angaben zu allen Inputs und Outputs ähnlich wie SIGHASH_ALL: welche zuvor empfangenen Coins ausgegeben werden und welche neuen Beträge mit Ausgabebedingungen entstehen. Eine Änderung erfasster Daten macht die Signatur ungültig. Das bedeutet aber nicht, dass jedes Byte signiert wird, etwa die anderen Signaturen. Andere zulässige Modi schützen einen anderen Umfang. Die Signatur selbst umfasst 64 Byte; bei einem anderen als dem Standardmodus kommt ein Typbyte hinzu, sodass dieses Element 65 Byte lang ist. Das ist weiterhin nicht die Größe des gesamten Inputs oder der Transaktion. [2]

Beim Signieren entsteht ein geheimer Nonce-Wert. Wird er mit demselben Schlüssel für unterschiedliche Nachrichten wiederverwendet, kann der private Schlüssel offengelegt werden. BIP340 beschreibt deshalb die Nonce-Ableitung genau und empfiehlt zusätzliche Zufallsdaten zum Schutz der Implementierung. Nutzer denken sich keine Nonce aus und notieren sie nicht in ihrer Sicherung. Eine geprüfte Signaturbibliothek übernimmt das; Improvisation kann hier ansonsten solide Kryptografie aushebeln. [1] [9]

Die mathematische Struktur von Schnorr-Signaturen ermöglicht Protokolle, bei denen sich mehrere Personen auf eine Nachricht einigen und gemeinsam signieren. Ein Beispiel ist MuSig2 nach BIP327. In der Grundform dieses Protokolls muss jedes Mitglied der festgelegten Gruppe mitwirken. Dafür braucht es Abstimmung, korrekte Schlüsselverarbeitung und ein eigenes sicheres Nonce-Verfahren. Beliebige fertige Signaturen einfach zu addieren reicht nicht aus. Auch die Unterstützung von Schnorr Signature sagt allein noch nicht, dass eine Wallet diese Zusammenarbeit beherrscht. [8]

Taproot bietet verschiedene Wege zum Ausgeben. Beim Key Path prüft das Netzwerk eine Signatur gegen den im Output festgelegten öffentlichen Schlüssel. Dahinter kann eine Person oder eine kooperierende Gruppe stehen. Beim Script Path wird das gewählte Skript offengelegt: ein Programm mit Bedingungen, die die Zahlung erfüllen muss. Tapscript ist die für Taproot verwendete Variante dieser Skriptsprache. Die Anweisung OP_CHECKSIGADD prüft eine Signatur und addiert bei Erfolg eins zu einem laufenden Zähler. Durch Wiederholung lassen sich mehrere getrennte Signaturen anhand einer erforderlichen Anzahl auswerten. Dieser skriptbasierte Multisig ist etwas anderes als eine aggregierte Signatur. Prüfen Sie bei der jeweiligen Wallet, wer mitwirken muss, was öffentlich wird und wie eine Wiederherstellung bei Schlüsselverlust möglich bleibt. [7] [2]

In einem Netzwerk ohne zentrale Entscheidungsstelle darf ein Knoten eine Signatur nicht akzeptieren, während ein anderer sie wegen abweichender Byte-Auslegung ablehnt. BIP340 beschreibt daher gültige Schlüssel, Signaturen und den Prüfablauf genau. Es ermöglicht auch Batch Verification, also die gemeinsame Prüfung mehrerer Signaturen zur Einsparung von Rechenaufwand. Dabei werden weder Blockchain-Einträge umgeschrieben noch Signaturen verschiedener Transaktionseingänge zusammengeführt. [1]

Eine gemeinsame Key-Path-Signatur kann wie die Signatur eines einzelnen Schlüssels aussehen. Aus ihr allein ist daher nicht unbedingt erkennbar, wie viele Personen zugestimmt haben. Beträge, Verbindungen zwischen Ein- und Ausgängen sowie der Transaktionszeitpunkt bleiben gewöhnlich beobachtbar. Schnorr Signature verschlüsselt die Zahlung nicht. Der tatsächliche Datenschutz hängt auch von der Taproot-Nutzung, dem Verhalten der Wallet und den Umständen der Zahlung ab. [2] [3]

Für Nutzer zählt eine Wallet, die Empfänger, Betrag und Gebühr richtig anzeigt und eine verlässliche Wiederherstellung erlaubt. Entwickler prüfen zusätzlich die genaue BIP340-Unterstützung, Testvektoren, Nonce-Verarbeitung und das Verhalten bei Fehlern. Der Name eines Algorithmus garantiert nicht die Qualität des gesamten Produkts. Eine gute Bibliothek wie libsecp256k1 übernimmt die kryptografische Berechnung; sie entscheidet nicht, ob ein Mensch die angezeigte Zahlung wirklich freigeben sollte. [4] [9] [6]