Das große Taproot-Upgrade: Mythen und Wahrheiten

Vergangene Woche wurde mit Taproot eines der wichtigsten Upgrades in der Geschichte von Bitcoin aktiviert. Doch was es konkret leistet, ist schwer zu verstehen und wird nicht selten falsch dargestellt. Wir haben daher einen Experten gefragt.

Vergangene Woche wurde Taproot aktiviert, eines der größten Bitcoin-Upgrades aller Zeiten, auf das die Community schon seit Jahren sehnsüchtig wartet. Doch was genau ist Taproot? Und was leistet es?

Wer mit dieser Frage die Nachrichten zu Taproot liest, wird ziemlich viel Konfusion ernten. Daher beginnt dieser Artikel mit einer kleinen Übersicht darüber, was die anderen schreiben.

Wenn schon Presseagenturen über ein Bitcoin-Upgrade berichten …

Eine der bemerkenswertesten Eigenschaften von Taproot ist, dass es sich um das erste Upgrade von Bitcoin handelt, das der Presseagentur DPA eine Meldung wert war. Das erklärt, warum man plötzlich in fast jedem Medium, von der Süddeutschen und FAZ über den Wiener Standard zur Kleinstadt-Gazette, Informationen über Taproot findet. Oder, besser gesagt: Missinformationen.

Taproot habe, erläutert Finanzen.net, eine “weitreichende Bedeutung für die Bitcoin-Blockchain”. Das Upgrade mache Bitcoin “noch agiler und flexibler” und ebne “den Weg für wichtige technologische Neuerungen.” Die FAZ und viele andere Zeitungen zitieren die DPA-Meldung, das Upgrade bringe “mehr Privatsphäre, weniger Speicherbedarf und sinkende Kosten.”

All das bleibt so vage, dass es weder falsch noch richtig sein kann. Wenn man es konkreter wissen will, erfährt man eher weniger, und wenn, dann gerne falsch oder irreführend. So meint Finanzen.net, durch Taproot werde “statt mehrerer öffentliche Schlüssel […] bei Zahlungen nur noch ein einziger öffentlicher Schlüssel erzeugt”, was, sieht man von der Begriffsverwirrung ab, bestenfalls halbrichtig ist. Darüber hinaus ermögliche Taproot “komplexere Smart Contracts auf der Bitcoin-Blockchain”, weshalb Bitcoin womöglich bald in Konkurrenz zu Ethereum treten könne.

In der FAZ erfährt man, dass die Schnorr-Signaturen “beim Bitcoin für mehr Privatsphäre sorgen”. Die Zeitung bzw. die DPA hat dafür den Blockchain-Professor Philipp Sandner um ein Statement gebeten, der doziert, dass “durch diese Schnorr-Transaktionen … ein Bündel von Transaktionen mit einer einzelnen Signatur freigebenen” werden. Auch ein Professor kann zuweilen so falsch liegen, dass man gar nicht weiß, wo man anfangen soll.

Am kompetentesten informiert noch Heise über Taproot. Das IT-Magazin erklärt, das Upgrade führe den “Pay-to-Taproot (P2TR) Transaktionstypen” ein, “welcher die Konzepte von Schnorr-Signaturen und ‘Merklized Alternative Script Trees’ vereint.” Doch auch Heise gerät ins Schwimmen, wenn das Magazin behauptet, Taproot erhöhe die Privatsphäre bei Transaktionen oder dass man durch Schnorr eine Transaktionen mit einer aggegierten Signatur unterschreiben könne.

Das ist bestenfalls halbrichtig und zeigt vor allem, wie schwierig es ist, ein technisch anspruchsvolles Upgrade wie Taproot zu verstehen – und zu erklären.

Ein Update wie ein Wrap

Wir versuchen, ein wenig Ordnung ins Taproot-Chaos zu bringen. Dazu haben wir uns mit Mark Erhardt erhalten, im Internet auch bekannt als Murch. Mark arbeitet in New York bei Chaincode Labs, nachdem er zuvor für BitGo in Palo Alto tätig war. Näher als der Badener kann man den Zentren der Bitcoin-Entwicklung kaum kommen.

Mark hat uns geholfen, Taproot nicht nur konzeptionell besser zu verstehen, sondern auch zu begreifen, was das Upgrade nun konkret bedeutet.

Was ändert Taproot? Welche Vorteile liegen in dem Update?

Taproot besteht grob gesagt aus zwei Komponenten: Aus Schnorr-Signaturen und einem Scriptbaum. Beide Bestandteile sind unabhängig voneinander, greifen aber zusammen, und jedes für sich ist nicht ganz einfach zu verstehen. Das ist eine der Hürden, um zu begreifen, was Taproot wirklich leistet – und was nicht.

Schnorr – der bessere ECDSA

Am einfachsten zu verstehen sind Schnorr-Signaturen. Diese waren, erklärt Mark, schon vor dem von Bitcoin verwendeten Signatur-Algorithmus ECDSA da.

“Das Signaturverfahren ist super interessant, aber der Erfinder, Klaus-Peter Schnorr, hat es patentieren lassen. Weil die Patentgebühr zu teuer war, haben andere Kryptographen ECDSA erfunden, um ebenfalls auf Basis von elliptischen Kurven zu signieren. Mittlerweile ist der Patentschutz aber erloschen.”

ECDSA ist gut, sogar sehr gut, weshalb Satoshi den Algorithmus für Bitcoin ausgewählt hat. Doch es ist nicht ganz so gut wie Schnorr, und ohne den Patentschutz hätte es wohl für niemanden einen Grund gegeben, ECDSA anstatt Schnorr zu verwenden.

Der wichtigste Unterschied liegt in einem kleinen, aber teils entscheidenden Detail: „Die Signaturen sind bei ECDSA nicht linear, bei Schnorr sind sie es”, erklärt Mark. “Wenn ein Signaturschema linear ist, kann man mehrere Signaturen so aggregieren, dass das Aggregat die Prüfung erlaubt. Das geht bei nicht-linearen Schemata, wie ECDSA, so nicht.”

Theoretisch stimmt also, was die FAZ und Heise behaupten: Man könnte durch Schnorr alle Signaturen in einer Transaktion zu einer einzigen zusammenfassen. Wenn eine Transaktion viele Inputs hat – sie also viele Coins zusammenfügt – muss man derzeit jeden Input signieren und jede Signatur in die Blockchain schreiben. Das macht einen Großteil der Transaktionsdaten aus. Schnorr könnte dies tatsächlich ändern.

Könnte! Denn “diese Aggregierung hat es leider nicht ins Taproot-Upgrade geschafft”, stellt Mark klar. “Das hätte zusätzliche Definitionen und Diskussionen erfordert, daher hat man sich entschieden, es erst später zu machen.“

Signaturen heimlich aggregieren

Dennoch wird die Aggregierung von Schnorr-Signaturen mit Taproot schon jetzt möglich. Aber eben nicht bei normalen, sondern nur bei Multisig-Transaktionen. Multisig bedeutet, dass zwei oder mehr Parteien eine Transaktion signieren müssen, damit Coins von einer speziellen Adresse (Multisig-Adresse) ausgegeben werden können.

„Nehmen wir an, wir legen zusammen eine Wallet an, bei der wir nur Geld ausgeben können, wenn wir beide signieren. Das wäre ein ‘2 von 2 Multisig’. Dank Taproot können wir unsere öffentlichen Schlüssel aggregieren: Du gibst mir deinen öffentlichen Schlüssel, ich verbinde ihn mit meinem, und das Ergebnis ist nicht von einer normalen Adresse zu unterscheiden. Man kann also nicht erkennen, dass es eine geteilte Wallet ist.”

Dieses „nicht-erkennen-können“ ist der maßgebliche Grund, weshalb gesagt wird, Taproot verbessere die Privatsphäre.

Bisher konnte man Multisig-Adressen gut erkennen. Sie begannen mit einer drei, anstatt mit einer eins wie traditionelle Adressen. Durch SegWit wurde das ein wenig aufgeweicht, da eimn Format SegWit-Adressen auch mit einer 3 beginnt. Dennoch schaffen die verschiedenen Adress-Typen Unterschiede, die die Privatsphäre von Bitcoin teilweise untergraben.

Mit Taproot kann man solche Unterschiede komplett einebnen. Egal welche Ausgabebedingungen eine Adresse verkörpert – eine Signatur, mehrere Signaturen, Timelocks, Smart Contracts – sie sehen alle gleich aus.

Dafür jedoch reichen Schnorr-Signaturen alleine nicht aus. Denn diese greifen nur bei einfachen Multisig-Konstruktionen: “2 von 2”, “3 von 3”, und so weiter. In der Praxis sind aber andere Modelle beliebter, nämlich sogenannte Threshold-Signaturen, auf deutsch: Schwellensignaturen, etwa “2 von 3”: Eine dritte Partei hat einen Backup-Schlüssel und springt ein, wenn ein anderer Schlüssel verloren geht, oder schlichtet, wenn die beiden anderen uneinig sind.

Bei solchen Modellen funktioniert die Aggregierung durch Schnorr-Signaturen nicht. Daher müssen wir an dieser Stelle über den zweiten Teil von Taproot reden: den Script-Baum.

Ein Scriptbaum für die anderen Fälle

Marks ehemaliger Arbeitgeber, der Wallet-Provider BitGo, bietet eine klassische “2 von 3″-Konstruktion: Es gibt drei Schlüssel. Einen hat der Kunde, einen BitGo, und der dritte ist ein gut gesichertes, kalt verwahrtes Backup. Von diesen drei Schlüssel braucht man zwei, um eine Transaktion zu senden, was üblicherweise die von Kunde und BitGo sind.

„Es gibt eine Erwartung, welche beiden Schlüssel verwendet werden. Diese kann man nun mit aggregierten Schnorr-Signaturen bedienen. Wir bilden also einen P2TR-Output mit den Schlüsseln von dir und von BitGo, und wenn der Normalfall eintritt, können wir mit einer aggregierten Signatur unterzeichnen.”

Diese Art, Transaktionen durch zwei Parteien zu signieren, ist die eleganteste, einfachste und schönste Art, dies zu tun. Im Vergleich dazu ist die aktuelle Methode durch “P2SH” (Pay-to-Script-Hash)-Adressen geradezu monströs komplex.

Was aber wenn es zum Backup-Fall kommt? Wenn ich meinen Schlüssel verlieren, und BitGo mit dem Backup-Schlüssel signiert? Oder wenn BitGo ausfällt und ich den Backup-Schlüssel ins Spiel bringen muss?

“Diese anderen, nicht-erwarteten Pfade sind als Blätter in den Scriptbaum eingeflochten, den Taproot eingeführt hat”, erklärt Mark. Und natürlich schreit diese Erklärung danach, selbst erklärt zu werden.

Von den Blättern zur Wurzel

Ein Scriptbaum ist im Grunde “nur” ein Merkle- oder Hashbaum mit Scripten. Abe was ist ein Hashbaum?

Ein Hashbaum ist eine besondere Anordnung einer Vielzahl von Hashes. Nehmen wir als Beispiel an, wie haben vier Bitcoin-Transaktionen und bilden von diesen die Hash. Dann hätten wir vier Hashes. In einem Hashbaum nennt man sie die “Blätter”.

Das Ziel der Übung ist es, von den Blättern über die Zweige zur Wurzel des Hashbaumes vorzustoßen. Dazu fügen wir zuerst den ersten und zweiten Hash zusammen und hashen das. Dasselbe machen wir mit dem dritten und vierten. Die beiden Hashes, die wir als Ergebnis haben – die Zweige – hashen wir ebenfalls. Damit haben wir die Wurzel: Eine Hash, die für eine Vielzahl an Hashes steht.

Was bringt eine solche Wurzel? Sie erlaubt es, durch eine einzelne Hash eine Vielzahl an Daten zu beweisen. Ein Beispiel ist ein Bitcoin-Block: Die Miner nehmen eine große Menge Transaktionen – in der Regel einige Tausend – und bilden aus diesen die Wurzel des Hashbaumes. Diese Wurzel ist die Basis des Minings, und sie erlaubt es, dass jeder prüfen kann, ob ein Block gültig ist.

Bei dem durch Taproot eigeführtem Scriptbaim ist jedes “Blatt” eine Möglichkeit wie man Bitcoins ausgeben kann – ein Script. Die oben genannte Multisig-Adresse enthält nicht nur das Aggregat von zwei öffentlichen Schlüsseln, sondern auch die Wurzel des Scriptbaumes.

Wenn nun der nicht-erwartete Fall eintritt, dass ich mit meinem und dem Backup-Schlüssel signiere, weil BitGo ausfällt, passiert das folgende, erklärt Mark:  “Ich offenbare das entsprechende Skript, welches in einem Blatt des Script-Baumes hinterlegt ist. Um zu beweisen, dass die ursprüngliche Adresse diese Ausgabebedingungen kodiert, offenbare ich die Hashes anderer Blätter und Zweige, so dass die Wurzel rekonstruiert werden kann. Dann erfülle ich das im Blatt enthaltene Script mit Signaturen von den beiden Schlüsseln.”

Wir haben also ein Verfahren, bei dem Multisig-Transaktionen in der Regel – beim Eintritt des erwarteten Falles – eleganter, einfacher und auch privater ablaufen. Erst in den nicht-erwarteten Fällen greift der Script-Baum. Das ist im Ergebnis ähnlich komplex wie die P2SH-Methode – ist aber etwas privater.

Denn bei P2SH wird das gesamte Script gehasht, welches alle Möglichkeiten enthält, wie Coins auszugeben sind. Um eine gültige Transaktion zu schreiben, muss ich den Reintext des Scriptes vorweisen. Ich muss also öffentlich machen, welche öffentlichen Schlüssel involviert sind, selbst wenn sie gar nicht zum Einsatz kommen.

Bei P2TR hingegen reicht es, wenn ich die Möglichkeit, die tatsächlich eintritt, im Klartext in die Transaktion schreibe. Alle anderen Optionen bleiben verschleiert.

Der Durchbruch für Multisig

Man muss nicht darüber diskutieren, ob Taproot elegant ist. Das ist es. Der Script-Baum ist eine sinnvolle Ergänzung zu den Schnorr-Signaturen. Es ist verständlich, dass ein Entwickler wie Mark begeistert von Taproot ist und es kaum erwarten kann, dass das Upgrade in allen Wallets ankommt.

Aber diejenigen, für die technische Eleganz kein Selbstzweck ist, sondern ein Mittel, dürften sich jetzt fragen: Was bringt es in echt? Also was kann Bitcoin mit Taproot nun besser als vorher?

„Multisig ist ein wesentlich sichererer Standard, um Geld zu verwalten,” sagt Mark. “Man kann Backups anlegen, und es schwieriger machen, Geld auszugeben. Das macht einen weniger angreifbar.“

Bisher aber aber hatten Multisig-Verfahren erhebliche Nachteile: Sie waren oft komplex, sowohl für den User als auch die Entwickler, sie schränkten die Privatsphäre ein und kosteten mehr Gebühren. All diese Nachteile fallen mit Taproot weg. „Man gibt weniger private Informationen her, man verrät weniger über sein Setup, und man kann mehr machen mit weniger Daten auf der Blockchain.“

Mark hofft, dass Taproot Multisig zum Durchbruch verhelfen wird. Dass mehr Wallets Multisig einführen, es bessere Standards geben wird, und dass die Usererfahrung, die derzeit oft noch grottig ist, besser wird.

Was Taproot nicht leistet

Trotz aller Begeisterung warnt Mark vor überzogenen und falschen Erwartungen. Damit wären wir wieder da, wo wir angefangen haben. Bei der DPA-Meldung und ihrer Interpretation in den Redaktionsstuben.

„Manchmal heißt es, Taproot bringe DeFi zu Bitcoin, weil es Smart Contracts ermöglicht. Das ist falsch. Smart Contracts gibt es schon, und alles, was Taproot kann, war auch schon vorher möglich – es war nur komplizierter, teurer und weniger privat.“

Auch zur Privatsphäre mit Taproot kursieren einige falsche Vorstellungen. „Gestern las ich in einer großen deutschen Zeitung, Bitcoin werde durch Taproot anonymer. Auch das ist nicht wahr. Man kann zwar nicht mehr sehen, ob eine oder mehrere Parteien signieren. Aber die Adresse ist ja weiterhin pseudonym, und man sieht weiterhin, welche Coins ausgegeben werden.“

Blockchain-Analysten werden auch nach Taproot keine Probleme damit haben, Wallets und Adressen wie bisher zu analysieren und zu clustern. „Man lernt nur etwas weniger über das Setup unter der Haube. Ob es eine normale Adresse ist, ein Lightning-Channel oder ein Multisig-Setup, ist nicht mehr zu sehen. Die generelle Nachverfolgbarkeit des Geldflusses bleibt aber dieselbe.“

Nun ist das Ökosystem am Zug

Wie so oft bei Bitcoin dauert es einige Zeit, bis ein Upgrade auch in den Wallets und bei den Usern ankommt. Man denke nur an SegWit. Das Upgrade brauchte lange, bis es sich auf einen Großteil der Transaktionen erstreckte, und noch länger, bis der Support für die bech32-Adressen weithin ausgerollt war.

Murch hofft, dass es bei Taproot schneller gehen wird. „BitGo Wallets können bereits mit Taproot Coins empfangen. Das zeigt, dass es dieses Mal schneller gehen kann.“

Um zu verstehen, worum es dabei geht, und warum es nicht ganz einfach ist, muss man ein paar weitere technische Details kennen. Auf die Gefahr hin, euch zu überfordern, müssen wir über die involvierten Adressformate reden.

• Die Standard-Adressen heißen “Pay-to-Public-Key-Hash” (P2PKH) und beginnen mit einer 1.
• Mit einer 3 beginnen die “Pay-to-Script-Hash” (P2SH)-Adressen, über die wir bereits geredet haben. Diese wurden für Multisig und andere Smart Contracts wie Time-Locks verwendet.
• Auch SegWit baute zunächst auf Adressen auf, die mit einer 3 begannen: Die “Nested SegWit Adresses” oder auch – sorry: “Pay to Script Hash Pay to Witness Public Key Hash” (P2SH-P2WPKH). Hier wurde mehr oder weniger das Script für SegWit gehasht und in eine P2SH-Adresse überführt. So konnte SegWit weniger disruptiv eingeführt werden.
• Die nativen SegWit-v0-Adressen, oder auch Pay to Witness Public Key Hash (P2WPKH) Adressen, die technisch effizienter funktionieren, nutzen das bech32-Format. Dieser neu entwickelte Standard sieht vollkommen anders aus, die Adressen sind länger, bestehen nur noch aus Kleinbuchstaben und fangen mit “bc1” an.

Auch Pay-to-Taproot (P2TR) verwendet den bech32-Standard. Allerdings gibt es einen kleinen Unterschied bei der Generierung der Adressen, weshalb die bisher verwendeten v0-Adressen nicht kompatibel sind. Das ist Absicht, um zu verhindern, dass jemand Geld verliert.

“In der Vorbereitung für Taproot haben wir entdeckt, dass manche Wallets die Witness-Version in bech32-Adressen ignorierten und Outputs immer als Native-Segwit-v0 definierten,” erklärt Mark.  “Wenn eine dieser Wallets Geld an eine P2TR-Adresse gesendet hätte, wäre im Output zwar das P2TR-Skript kodiert worden, aber wegen des Versionsfehlers zum Ausgeben das Erfüllen eines P2WPKH-Skript notwendig gewesen. Der Empfänger hätte das Geld nicht mehr ausgeben können.”

Für Mark ist es daher wichtig, dass zunächst möglichst viele Wallets es erlauben, Geld an Taproot-Adressen zu senden. Denn bevor dies nicht weithin möglich ist, wird es für User immer nachteilig sein, diese Adressen zu verwenden.

Die Core-Entwickler haben ihre Arbeit gemacht. Doch die Arbeit für das Ökosystem beginnt an dieser Stelle erst.