Was ist Taproot? Das Bitcoin-Upgrade einfach erklärt

Nun, da die Aktivierung des Bitcoin-Upgrades immer wahrscheinlicher wird, wollen wir uns einmal anschauen, was es mit Taproot auf sich hat. Was ist Taproot, was für Vorteile bringt es und was für neue Funktionen werden dadurch ermöglicht?

Inhalt

  • Was sind Ausgabe-Konditionen?
  • Merklized Alternative Script Trees
  • Schnorr-Signaturen
  • Was bedeutet das?
  • Was wird dadurch möglich?

Was sind Ausgabe-Konditionen?

Bevor wir uns Taproot näher anschauen, müssen wir erst einmal verstehen, wie eine UTXO (Unspent Transaction Output) aufgebaut ist. Bitcoin-Transaktions-Outputs enthalten immer eine Ausgabe-Kondition. Diese beschreibt, welche Konditionen erfüllt sein müssen, damit dieser Coin (bzw. diese UTXO) wieder ausgegeben werden kann. Diese Konditionen können zum Beispiel sein:

  • Nur der Besitzer eines bestimmten Public-Keys kann diese UTXO ausgeben
  • Nur der Besitzer eines Hashes eines Public-Keys kann diese UTXO ausgeben, nachdem er zeigt, dass sein Public Key zum Hash gehört
  • Diese UTXO kann nur nach einer bestimmten Zeit (Blockhöhe) ausgegeben werden

Diese Ausgabe-Konditionen sind im Script der Transaktion hinterlegt. In modernen Transaktionstypen (P2SH) wird dieses Script zwar nur noch als Hash abgelegt, doch wenn diese Transaktion wieder ausgegeben wird, muss das gesamte Script veröffentlicht werden. Das bedeutet, dass alle Ausgabe-Konditionen Teil dieser nächsten Transaktion sein müssen, was nicht nur dazu führt, dass die Transaktion weniger privat ist, sondern auch dazu, dass die Transaktion bedeutend größer wird, was Blockspace und somit Gebühren kostet.

Taproot Upgrade

MAST

Merklized Alternative Script Trees sind eine Möglichkeit, Teile dieses Skriptes zu verbergen. Durch einen Merkle Tree müssen nicht mehr alle Konditionen veröffentlicht werden, sondern nur noch Teile.

Bei einem Merkle Tree werden unterschiedliche Informationen jeweils zu zweit gehasht und daraufhin so oft erneut gehasht, bis letztendlich ein einziger Hash (die Merkle Root) übrig bleibt. Durch die Kombination der beiden Quell-Hashes wird die Validität des resultierenden Hashes bewiesen. Schauen wir uns das einmal an einem Beispiel an:

Ein Merkle-Tree mit 4 Konditionen

Wenn ich die Transaktion mit den Konditionen A,B,C und D ausgeben möchte, weil ich Kondition D erfülle, aber möglichst wenig darüber verraten möchte, kann ich Hash(KonditionA+B) und zusätzlich Hash(Kondition C) und Kondition D veröffentlichen. Beim Validieren wird erst Kondition D zu Hash(Kondition D) gehasht und daraufhin werden Hash(Kondition C) und Hash(Kondition D) gehasht und aus dem resultierenden Hash(KonditionC+D) wird gemeinsam mit dem Hash der Hash(KonditionA+B) der Gesamthash des Skripts (Hash(Skript)) errechnet. Konditionen A und B bleiben somit geheim und es wird nur Kondition D verraten.

Somit muss bei der Einlösung der UTXO nur eine Ausgabe-Kondition und ein weiterer Hash veröffentlicht werden.

Wie schon am Diagramm zu erkennen, müssen durch MAST deutlich weniger Informationen in der Transaktion veröffentlicht werden. So werden Blockspace und Gebühren gespart und Privatsphäre geschützt.

Schnorr-Signaturen

Schnorr Signaturen sind eine Alternative zu den bisher von Bitcoin verwendeten ECDSA-Signaturen. Diese gelten generell als etwas sicherer, da bei ihnen ein Sicherheitsbeweis erbracht werden kann, den es für ECDSA noch nicht gibt.

Schnorr-Signaturen sind statt den bisherigen 72 Byte nur 65 Byte lang. Schnorr-Pubkeys wiederum nur 32 statt 33 Byte lang. Kleinere Signaturen und Pubkeys sind insofern von Vorteil, als dass sie weniger Blockspace einnehmen und Transaktionen dadurch günstiger werden.

Eine weitere Funktion von Schnorr Signaturen ist Key-Aggregation. Mit Key-Aggregation kann eine Transaktion an einen einzelnen Pubkey Q gebunden (Pay to Pubkey) werden, dieser Pubkey kann nun aber aus mehreren verschiedenen Pub-Keys und Skripts erzeugt worden sein. Dadurch lassen sich diese im Pubkey Q “verstecken”. Onchain wird dann nur dieser Pubkey Q veröffentlicht.

Wer beweisen kann, dass er Pubkey Q erzeugen kann, kann die UTXO ausgeben. Das funktioniert im oberen Beispiel entweder indem man über den Privatekey für Pubkey A verfügt oder eine der 4 Ausgabe-Konditionen erfüllt.

Es gibt noch dutzende weitere Vorteile von Schnorr Signaturen, wie Scriptless Scripts, Threshold Signatures, Blind Signatures etc.. Wer mehr darüber lesen möchte, findet hier detailierte Erklärungen.

Was bedeutet das jetzt?

Weil bei einem P2TR-Output nicht mehr das gesamte Skript veröffentlicht wird, kann nicht unterschieden werden, was hinter der eigentlichen Transaktion steckt. Handelt es sich um ein MultiSig-Wallet, einen Lightning-Kanal oder um einen komplexen Smart-Contract?

Dadurch, dass weniger Daten in einer Transaktion gespeichert werden, werden besonders komplexe Transaktionen deutlich günstiger.

Was wird dadurch möglich?

Payment Pools

Bei Payment-Pools handelt es sich um eine Alternative zu CoinJoins. Die Idee ist recht simpel: Wie bei einem normalem MultiSig-Account senden mehrere Personen ihre Beträge an eine einzelne Taproot-Adresse. Durch Key-Aggregation ist diese Adresse an einen Pubkey und ein Skript gebunden. Dadurch sieht diese Adresse auf der Blockchain aus, wie jede andere.

Während der Payment-Pool besteht, können die User untereinander koordinieren, welche Zahlungen bezahlt werden. Hat Alice 2 BTC eingezahlt, erlauben ihr die anderen Teilnehmer lediglich 2 BTC dieser Adresse auszugeben. Ungültige Transaktionen werden von den anderen Teilnehmern nicht signiert.

Möchte Bob aus dem Payment-Pool aussteigen, kann über das Skript der Pool entweder aufgelöst werden und alle User erhalten ihre jeweiligen Anteile zurück, oder die Beträge werden an eine neue Adresse mit neuen Payment-Pool-Bedingungen, ohne Bob, gesendet.

Mehr über Payment Pools findet ihr hier.

CoinSwaps

Auch bei CoinSwaps handelt es sich um eine Privatsphäre-Verbesserung. Durch CoinSwaps können Alice und Bob UTXOs miteinander tauschen, ohne, dass diese auf der Blockchain miteinander verbunden werden können.

Alice sendet eine Transaktion an CoinSwap Adresse 1, Bob sendet eine Transaktion an CoinSwap Adresse 2. Der Clou: Die Transaktionen von CoinSwap Adresse 1 und 2 an die jeweils andere Partei passieren gleichzeitig und verhindern somit Betrug.

Durch Taproot kann auch hier onchain nicht nachvollzogen werden, dass es sich um einen CoinSwap handelt.

PTLCs

Aktuell funktioniert das Lightning-Netzwerk über HTLCs (Hashed Time Locked Contracts), die während einer Zahlung jeweils zwischen Channelpartnern ausgetauscht werden. Point Time Locked Contracts sind eine Weiterentwicklung von HTLCs, die es ermöglichen, das Preimage für jeden Hop zu verändern. Aktuell können alle Hops einer Lightning-Zahlung über das Preimage miteinander verbunden werden. PLTCs führen hier zu besserer Privatsphäre von Zahlungen.

Mit Hilfe von PLTCs können z.B. auch DLCs auf Lightning abgewickelt werden, indem eine vertraute dritte Partei eine Zahlung authorisieren kann.

PTLCs sind bereits jetzt schon mit ECDSA-Signaturen möglich, doch um für einen Standard zu sorgen, wurde mit der Implementierung auf das Taproot-Upgrade mit Schnorr-Signaturen gewartet.

Fazit

Bei Taproot handelt es sich in erster Linie um ein Privatsphäre-Upgrade. Taproot-Transaktionen mit komplexen Skripten können nicht mehr von einfachen Taproot-Transaktionen unterschieden werden. Gleichzeitig können durch P2TR aber auch Transaktionsgebühren gespart und einige neue komplexe Funktionen ermöglicht werden.

Es wird spannend zu beobachten, welche weiteren interessanten Ideen das Taproot-Upgrade ermöglichen wird. Sollte das aktuelle Speedy-Trial-Aktivierungsverfahren glücken, wird Taproot im Herbst dieses Jahres aktiviert.

Spende uns:

Wenn dir dieser oder einer unserer anderen Beiträge gefallen hat, würden wir uns über eine kleine Spende freuen:

1 comment

  1. Hallo Btc21 Team,

    Ich hätte einen kleinen Kommentar zur letzten Potcastfolge: ihr macht echt gute Arbeit und ich höre euren Podcast echt gerne. Ihr tragt auch dazu bei, dass ich merke wie ich immer mehr zum Bitcoin maxi werde 😉, aber wenn die Folge hauptsächlich daraus besteht sich über andere Projekte lustig zu machen und abfällig ohne viel Substanz darüber zu reden und sich über Leute mit einer anderen Meinung von oben herab zu äußern, dann tut ihr niemandem einen Gefallen. Schaut mal in andere Foren, wie sich dort immer mehr das Narrativ vom hochnäsigen, arroganten bitcoiner festigt , sowohl von nocoinern als auch von shitcoinern. Dieses Narrativ füttert ihr in eurer letzten Folge einfach nur. Bei vielen Punkten habt ihr in der Sache recht, aber dann sollte trotzdem eine sachliche Auseinandersetzung stattfinden und nicht nur „haha schaut euch die idioten an die ethereum besser finden als binance“ oder „Thelen ist ein verblendeter depp“

Schreibe einen Kommentar