Seite 2: Schnorr-Signaturen

Inhaltsverzeichnis

Die Schnorr-Signatur wurde zwischen 1989 und 1991 vom deutschen Mathematikprofessor Claus Peter Schnorr entworfen. Sie ist ein kryptografisches Verfahren für digitale Signaturen und hält jetzt Einzug (BIP340) in Bitcoin. Bei einer digitalen Signatur berechnet ein Sender mithilfe eines geheimen Signaturschlüssels (Private Key) einen Wert zu einer digitalen Nachricht aus beliebigen Daten. Dieser Wert ermöglicht es jedem, mithilfe des öffentlichen Verifikationsschlüssels (Public Key) die nichtabstreitbare Urheberschaft und Integrität der Nachricht zu prüfen.

Aktuell wird in Transaktionen von Bitcoin der "Elliptic Curve Digital Signature Algorithmus" (ECDSA) für Signaturen verwendet. Warum die unbekannte Person, die Bitcoin erfunden hat, nicht von Beginn an auf Schnorr-Signaturen setzte, ist unklar. Ein Grund könnte die damals geringe Verbreitung von Schnorr-Implementierungen in verschiedenen kryptografischen Bibliotheken sein. Das Patent von Claus Peter Schnorr auf die gleichnamige Signatur lief zumindest kurz vor Erscheinen von Bitcoin ab.

Schnorr-Signaturen bieten einige Vorteile gegenüber ECDSA:

• Diese sind nach dem Random-Oracle-Modell beweisbar sicher, wenn eine hinreichend zufällige Hash-Funktion verwendet wird und das in der Signatur verwendete Problem des diskreten Logarithmus elliptischer Kurven hinreichend schwer ist. Für ECDSA gibt es solchen einen Beweis nicht.
• Schnorr-Signaturen sind nicht formbar (Non-Malleability). Einfach ausgedrückt bedeutet die Formbarkeit von Signaturen, dass es technisch möglich ist, die Signatur einer Transaktion zu ändern, bevor sie bestätigt wird.
• Signaturen werden in Zukunft nur noch 64 Byte statt bisher bis zu 72 Byte groß sein.
• Schnorr codierte Public-Keys sind nur noch 32 Byte statt 33 Byte groß.

Viele Schlüssel kombiniert

Besonders spannend ist die Linearitätseigenschaft von Schnorr-Signaturen. Diese ermöglicht das Konzept von Multisignaturen mit "Key-Aggregation". Im Wesentlichen können dadurch mehrere Unterzeichner einer Transaktion mit mehreren Unterschriften ihre öffentlichen Schlüssel zu einem aggregierten öffentlichen Schlüssel kombinieren. Dies war mit ECDSA nur über Umwege durch P2SH/P2WSH möglich. Dieser kombinierte öffentliche Schlüssel lässt sich von außen dann nicht mehr von einem herkömmlichen Schlüssel (Single-Sig) unterscheiden.

Schnorr-Signaturen tragen ferner zu Platzeinsparungen in der Bitcoin-Blockchain bei und haben nach Aussage der Autoren von BIP340 gewissermaßen keine Nachteile.

Ausgabebedingungen auf Skripte verteilt

Neben der Schnorr-Signatur spielen "Merklized Alternative Script Trees" (MAST) bei Taproot eine wichtige Rolle. Der Name setzt sich aus den beiden Konzepten "Abstract-Syntax-Tree" (AST) und den in Bitcoin bereits verwendeten Merkle-Tree zusammen. MAST erlaubt es grob gesagt, Ausgabebedingungen einer Transaktion auf mehrere Skripte zu verteilen.

Mit "Pay-to-Taproot" (P2TR) wurde ein neuer Transaktionstyp ins Leben geschaffen, welcher unter anderem MAST verwendet. P2TR kennt zwei Wege, wie eine UTXO ausgegeben werden kann. Zum einen kann eine UTXO via Key-Path-Spending von einer Besitzerin eines privaten Schlüssels, der zum Public-Key passt, ausgegeben werden. Zum anderen kann eine UTXO via Script-Path-Spending ausgeben werden, wenn sich die Anforderungen eines beliebigen Skripts innerhalb des MAST erfüllen lassen.

Eine P2TR-Transaktion ist nach außen an einen einzigen Public-Key gebunden. Dieser öffentliche Schlüssel ist intern wiederum eine Kombination aus einem oder auch mehreren öffentlichen Schlüsseln und eines Skripts, welches aus der Merkle-Root mehrerer Skripte konstruiert wird. Schauen wir uns einmal den beispielhaften Aufbau von Ausgabebedingungen in einer P2TR-Transaktion an. Wir gehen davon aus, dass diese aus einer 2-aus-3-Multisignatur besteht. Ein beliebtes Setup, welches auch etliche Bitcoin-Service-Provider anbieten.

In unserem Beispiel verfügt der Service-Provider über einen Schlüssel (Casa-Key) und der Kunde über zwei Schlüssel. Ein Key (Cold-Key) wird in einem Cold-Storage aufbewahrt. Um die Satoshis ausgeben zu können, werden mindestens zwei Schlüssel benötigt. Insgesamt hat man drei Kombinationsmöglichkeiten, um an die Satoshis zu gelangen.

Dieses Design ermöglicht zwischen komplexen Skripten und einfachen Pay-to-Public-Key-Funktionen zu wählen. Das Ganze passiert erst zum Zeitpunkt der erneuten Ausgabe einer Transaktion. Beim Ausgeben der Transaktion muss dank MAST nicht jedes mögliche Skript offengelegt werden, sondern nur das Skript, dass tatsächlich zum Ausgeben der Satoshis benötigt wird.