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

Mehr Privatsphäre, weniger Speicherbedarf und bessere Abwicklung komplexer Skripte soll das Taproot-Update dem Bitcoin bescheren. Ein Blick unter die Haube.

Lesezeit: 12 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 129 Beiträge

(Bild: Svetlana Sotnikova/Shutterstock.com)

Von
  • Tim Rauhut
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.

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.

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.

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.

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..

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.