Taproot kommt: Erstes großes Bitcoin-Update seit 2017

Inhaltsverzeichnis

Seit 2017 hat der Bitcoin kein großes Protokoll-Upgrade erhalten. Das soll sich Mitte November ändern, wenn das Update namens Taproot aktiviert wird. Die Vorarbeiten dazu laufen schon seit Längerem. Bereits im Januar 2018 veröffentlichte der Bitcoin-Core Entwickler Gregory Maxwell einen ersten Entwurf zu Taproot auf der Bitcoin-Mailingliste. Schon damals war das Ziel des Entwurfs mehr Anonymität und Effizienz.

Die Grundlagen für Taproot wurden im turbulenten Bitcoin-Jahr 2017 durch die Einführung von Segregated Witness (SegWit) gelegt. Die Streitigkeiten um potenzielle Änderungen der Blockgröße und die Einführung von SegWit hatten schließlich zu einer Spaltung des Bitcoins geführt.

Abwärtskompatibles Update

Wie bei SegWit handelt es sich auch bei Taproot um einen Soft-Fork. Die Änderungen am Protokoll werden damit abwärtskompatibel sein. Das ist deshalb von Vorteil, weil es in einem dezentralen Netzwerk einige Zeit dauern kann, bis die Teilnehmer auf neue Software umsteigen und sämtliche Transaktionen auf ein neues Format umgestellt wurden. Aktuell verwenden rund 80 Prozent der Transaktionen im Bitcoin-Netzwerk das SegWit-Format.

Das Taproot-Upgrade bietet mit dem neuen Pay-to-Taproot (P2TR) Transaktionstypen, welcher die Konzepte von Schnorr-Signaturen und "Merklized Alternative Script Trees" (MAST) vereint, ferner wird die Privatsphäre bei Transaktionen erhöht und bei komplexen Ausgabebedingungen deutlich weniger Speicherplatz benötigt. Insgesamt setzt sich das Upgrade aus drei Bitcoin-Improvement-Proposals (BIPs) zusammen:

• Schnorr-Signaturen (BIP340)
• SegWit-Ausgabe-Konditionen(BIP341)
• Validierung von Taproot-Skripten (BIP342)

Die oben genannten BIPs definieren einen Standard für Schnorr-Signaturen und die Taproot-Konstruktion. Außerdem baut BIP341 auf dem früheren Vorschlag von Merklized Alternative Script Trees (MAST) auf. Um zu verstehen, was Taproot und Schnorr-Signaturen im Detail verbessern, werfen wir zunächst einen Blick auf den Istzustand von Bitcoin-Transaktionen.

Wie Alice den Cappucchino bezahlt

Eines der wichtigsten Konzepte in Bitcoin sind Transaktionen. Diese "transferieren" einen Wert in Form von Satoshis (Sats), der kleinsten Bitcoin-Einheit, von einer Adresse zu einer anderen Adresse im Bitcoin-Netzwerk. Also zum Beispiel von Alice in einem Café, die gerade einen Cappuccino mit Bitcoin bezahlt und an die öffentliche Wallet-Adresse von Kate sendet.

Eine Transaktion referenziert dabei in der Regel frühere Transaktionen als Transaktionsinputs. Ausnahme davon sind lediglich die Coinbase-Transaktionen, mit denen bei jedem neuen Block die Belohnung an den erfolgreichen Miner ausgeschüttet wird und so neue Bitcoins entstehen. Transaktionen sind nicht verschlüsselt. Somit ist es möglich, jede Transaktion, die in der Bitcoin-Blockchain persistiert wurde, zu durchsuchen und die Details einzusehen.

Ausgabebedingungen als Skript

In unserem Café-Beispiel überträgt Alice sozusagen die Eigentumsrechte an den ausgegebenen Satoshis für den Cappuccino an Kate. Wenn Kate mit diesen Satoshis später etwas kauft, würde sie wiederum die Eigentumsrechte an den Satoshis weitergeben. Der Betrag für den Cappuccino wird neben weiteren Informationen in einem Unspent Transaction Output (UTXO) gespeichert. Dort legt Alice fest, wer die Satoshis für den gerade bezahlten Cappuccino wieder ausgeben darf. Dieser Kontrakt wird in einer sogenannten Ausgabebedingung im Feld scriptPubKey der Transaktion festgehalten.

Ausgabebedingungen sind komplexe oder auch weniger komplexe Skripte, die in der dem Bitcoin eigenen Sprache Script verfasst werden. Script ist eine stackbasierte Sprache, die Forth ähnelt, und keine Turing-Vollständigkeit besitzt. Durch die Möglichkeit, Skripte mit eigener Logik anzureichern, wird auch gerne der Name "Programmable Money" für Bitcoin verwendet. Bei Ethereum und anderen Kryptowährungen wird auch von Smart Contracts gesprochen, wobei Ethereum auf Turing-Vollständigkeit setzt.

Verschiedene Transaktionstypen

Die Ausgabebedingungen für die Cappuccino-Transaktion von Alice könnte zum Beispiel lauten: Die Satoshis für den Cappuccino können nur von jemanden erneut ausgegeben werden, der eine gültige Signatur passend zur Wallet-Adresse (Public-Key-Hash) von Kate liefern kann. In diesem Fall wäre das nur mit dem Private-Key von Kate möglich. Der gerade beschriebene Transaktionstyp nennt sich Pay-to-Public-Key-Hash (P2PKH) und ist mit rund 78 Prozent die am häufigsten verwendete Transaktionsart.

Die Empfangsadresse bei einer P2PKH-Transaktion lässt sich anhand der führenden "1" in der Adresse gut in einem Block-Explorer erkennen. Die Ausgabebedingungen können aber auch komplexer formuliert werden, zum Beispiel in einem Multisignatur-Setup, bei dem das Skript gleich mehrere Signaturen erwartet. In so einem Fall sollte auf einen anderen Transaktionstypen zurückgegriffen werden: Mit Pay-to-Script-Hash (P2SH) werden komplexe Ausgabebedingungen durch einen Hash in der Transaktion im Feld scriptPubKey festgehalten. Die nicht gehashte Klartext-Version der Ausgabebedingung wird Redeem-Skript genannt..

Speicherplatz sparen

Soll eine P2SH-Transaktion erfolgreich ausgeben werden, muss sie das passende Redeem-Skript enthalten. Dieses muss mit dem vorher erzeugten "Redeem-Hash" übereinstimmen und weitere Daten wie Signaturen für die erfolgreiche Skriptauswertung enthalten. In einem komplexen Multisignatur-Setup oder generell bei komplexen Ausgabebedingungen kann das Redeem-Skript erheblichen Speicherplatz einnehmen. Auch wenn bei einem 3-aus-5-Multisignatur-Setup von 5 Signaturen lediglich 3 Signaturen zur Freigabe der Satoshis benötigt werden, beinhaltet das Redeem-Skript auch Abschnitte für sämtliche alternativen Wege.

Das schlägt sich in höheren Transaktionskosten nieder, denn für jedes Byte an Speicherplatz fallen Gebühren an. Ferner verrät es unnötig viele Details über sämtliche Skripte in den Ausgabebedingungen. Genau diesen beiden Probleme soll das Bitcoin Improvement Proposal 341 minimieren.

Schnorr-Signaturen

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.

Upgrades in einem dezentralen Netzwerk

Sämtliche Taproot-Funktionen sind für Wallets optional. So müssen bestehende Wallets ihre Funktionsweise nicht ändern und können bei Bedarf die neuen Möglichkeiten von Taproot einbauen und davon profitieren. Technisch gesehen sind die Voraussetzungen für den Soft-Fork mit Taproot bereits seit der Bitcoin-Core-Version 0.21.0 vorhanden. Der Begriff Soft-Fork wurde eingeführt, um diese Upgrade-Methode von einem nicht mit alten Versionen kompatiblen Hard-Fork zu unterscheiden. Ein Soft Fork ist eine abwärtskompatible Änderung der Konsensregeln, die es nicht aktualisierten Nodes ermöglicht, weiterhin im Konsens mit den neuen Regeln zu arbeiten.

Bevor die Änderungen im Netzwerk aktiviert werden können, wurde von der Bitcoin-Community entschieden, dass Bitcoin-Miner und Bitcoin-Mining-Pools ihre Bereitschaft zum Upgrade signalisieren müssen. Dazu wurde der Speedy-Trial -Mechanismus nach BIP9 implementiert und in Release 0.21.1 ausgerollt.

90 Prozent Zustimmung in 2.016 Blöcken

Innerhalb von 2.016 neu geschürften Blöcken müssen mindestens 90 Prozent der Miner ihre Bereitschaft zum geplanten Soft-Fork signalisieren. Ein Miner signalisiert seine Bereitschaft für ein geplantes Upgrade, in dem er im Versionsfeld des Block-Headers ein Bit setzt. Die Anzahl der Blöcke ist dabei nicht zufällig gewählt. Die Länge von 2.016 Blöcken entspricht genau einer Difficulty-Periode im Bitcoin-Netzwerk. Danach passt sich automatisch die Schwierigkeit für das Schürfen neuer Blöcke erneut an. Dies kann etwa hilfreich sein, wenn ungeplant größere Mengen an Rechenleistung das Netzwerk verlassen.

Werden die 1.815 Blöcke (90 Prozent) nicht in einer Difficulty-Periode erreicht, geht es wieder von vorne los. Für den Lock-In 3 bleiben jeweils 3 Monate Zeit. Am 12. Juni wurde die 90-Prozent-Marke innerhalb einer Difficulty-Periode erreicht und der Lock-In steht seitdem fest.

Taproot wird somit ab Block 709632 im Mainnet von Bitcoin aktiviert, voraussichtlich wird das am 16. November sein. Bis zu diesem Zeitpunkt sollten auch sämtliche Full-Nodes auf mindestens die Version 0.21.1 aktualisiert werden, denn am Ende wird die Einhaltung der neuen Konsensregeln von Full-Nodes und damit von allen im Netzwerk überprüft.

(axk)