Skip to main content

Upgrade für Bitcoin & Lightning: Was sind Eltoo und SIGHASH_ANYPREVOUT?

Am von
Das Wichtigste in Kürze:
  • Das Eltoo Protokoll ist ein alternativer Vorschlag, wie Lightning Kanäle aufgebaut und sicher genutzt werden können.
  • Der große Vorteil ist der konstant kleine Speicherbedarf gegenüber dem aktuellen LN Penalty Mechanismus.
  • Für Eltoo ist erst eine Soft Fork mit neuen Funktionen zum Signieren von Transaktionen notwendig (BIP-118).

In diesem Beitrag soll es darum gehen, wie „Eltoo“, ein Protokoll zur Verwaltung von Lightning Kanälen, funktioniert, welche Voraussetzungen dafür nötig sind und welche Vorteile es überhaupt bietet. Dafür schauen wir uns auch das Bitcoin Improvement Proposal 118 an, welches mit SIGHASH_ANYPREVOUT das notwendige Fundament liefert.

Bevor wir uns aber mit BIP-118 oder gar Eltoo befassen können, müssen wir zunächst den aktuellen Ausgangszustand im Lightning Netzwerk genauer unter die Lupe nehmen und verstehen, was es mit sogenannten Signature Hash Types überhaupt auf sich hat.

Hinweis: Es kann hilfreich sein, sich zunächst mit der Bitcoin Script Sprache und dem Konzept eines Unspent Transaction Outputs (UTXO) vertraut zu machen, um diesen Beitrag besser zu verstehen.

Was ist ein SIGHASH?

Normalerweise, wenn wir etwas unterschreiben, z.B. einen Vertrag, bestätigen wir, dass wir mit dem gesamten Dokument einverstanden sind. Bei Bitcoin Transaktionen ist das nicht anders: Die digitale Signatur, mit der bestätigt wird, dass ein Output ausgegeben werden darf, gilt in der Regel für die gesamte Transaktion, also für alle In- und Outputs. Verändert man irgendetwas an der Transaktion, wäre die Signatur sofort ungültig.

Doch sowohl im „echten Leben“ als auch bei Bitcoin Transaktionen reicht uns das nicht immer aus. Manchmal möchte man mit einer bestimmten Signatur nur einen abgegrenzten Teil eines Dokuments oder eben einer Transaktion unterschreiben, z.B. damit zusätzliche Details erst später ergänzt werden können.

In einer Bitcoin Transaktionen können wir deshalb signalisieren für welchen Teil der Transaktion eine Signatur gültig ist bzw. welcher Teil überhaupt unterschrieben wurde. Genau diese Information geben wir mit dem sogenannten SIGHASH an. Neben dem oben beschriebenen Normalfall (also ganze Transaktion wird unterschrieben) der einfach SIGHASH_ALL genannt wird, gibt es noch weitere Varianten, von denen wir uns einfach mal ein Beispiel anschauen.

SIGHASH_NONE

Mit SIGHASH_NONE signiert man, wie der Name schon andeutet, nichts. Genauer gesagt signiert man zwar alle Inputs, aber keine Outputs, was einem ermöglicht, einer Transaktion nachträglich einen (oder mehrere) Empfänger hinzuzufügen. Das kann man sich wie bei einem herkömmlichen Scheck vorstellen: Der Aussteller hat für einen bestimmten Betrag unterschrieben (das ist der Input) und der Empfänger kann mit diesem Betrag jetzt machen, was er möchte.

Weitere Typen wie SINGLE und Kombinationen mit ANYONECANPAY interessieren uns für den Moment nicht weiter. Wichtig ist nur zu verstehen, dass es bereits heute grundsätzlich die Möglichkeit gibt, nur bestimmte Teile einer Transaktion zu signieren und dass sich damit neue Anwendungsfälle eröffnen können.

LN Penalty

Bereits in unserem Beitrag über das Lightning Netzwerk gehen wir kurz auf den Mechanismus ein, der Betrugsversuche zwischen den Teilnehmern eines Lightning Channels verhindern soll.

Wenn Alice und Bob gemeinsam einen Lightning Channel öffnen, senden sie Bitcoin an eine Adresse, von der nur Ausgaben getätigt werden können, wenn beide damit einverstanden sind, also 2-von-2 gültigen Signaturen vorliegen (Siehe Multisignature Wallets).

Mit einer Transaktion, die von beiden signiert wurde, kann also die Aufteilung der Bitcoin im Channel (Balance) dargestellt und vor allem auch aktualisiert werden. Lightning Zahlungen sind im Hintergrund nichts anderes als das Austauschen und gegenseitige Signieren von solchen Commitment-Transaktionen. Vergleichbar sind diese nicht-veröffentlichten Transaktionen mit einem Vertrag, der laufend aktualisiert wird. Das Bitcoin Netzwerk ist dabei sozusagen der „Richter“, den man jederzeit einschalten kann, um den Vertrag durchzusetzen.

Das Problem: Die alten Verträge bzw. Transaktionen müssen irgendwie ungültig werden, da immer nur die aktuellste Version den „echten Zustand“ wiedergibt. Ansonsten könnte man mit einem älteren Vertrag, der für einen selbst von Vorteil ist, zum Richter rennen (also die Transaktion im Netzwerk veröffentlichen) und dem anderen Bitcoin stehlen!

Die technischen Details zur Lösung dieses Problems würden an dieser Stelle den Rahmen sprengen. Vereinfacht verraten sich Alice und Bob mit jedem neuen Vertrag, den sie schließen, ein Geheimnis über den vorherigen Vertrag. Mit diesem Geheimnis ist es möglich eine Klausel im alten Vertrag zu aktivieren, die einem erlaubt alle Bitcoin selbst zu nehmen und damit den Betrüger zu bestrafen (Penalty). Natürlich nur, sollte ein alter Vertrag tatsächlich veröffentlicht werden.

Aber was hat das eigentlich mit dem Thema dieses Beitrags zu tun? Um später den großen Vorteil von Eltoo zu verstehen, müssen wir zuerst das Problem von LN Penalty kennenlernen.

Alice muss alle alten Verträge und Geheimnisse, die sie mit Bob ausgetauscht hat, aufbewahren, und zwar so lange der Kanal geöffnet ist. Denn wenn Bob einen bestimmten alten Vertrag veröffentlicht, muss Alice das für genau diesen Vertrag richtige „Gegengift“ einsatzbereit haben, um Bob bestrafen zu können.

Der notwendige Speicherplatz skaliert also gleichmäßig mit der Anzahl an durchgeführten Lightning Zahlungen.

Jeder Zustand des Kanals muss gespeichert und griffbereit sein.

Wenn du also unserer Blocktrainer Lightning Node ein paar weitere solcher „Aktenordner mit Verträgen“ aufbinden willst, dann unterstütze uns doch mit einer kleinen Spende! 😉

SIGHASH_ANYPREVOUT

Mit zwei neuen SIGHASH Typen, ANYPREVOUT und ANYPREVOUTANYSCRIPT, soll in Zukunft eine neue Weise ermöglicht werden, Bitcoin Transaktionen zu signieren, die eben vor allem für das Lightning Netzwerk spannende Folgen hat.

Wir erinnern uns: Die einfachen SIGHASH Typen aus dem ersten Abschnitt beschränkten sich allein auf die Frage, welche In- bzw. Outputs unterschrieben werden. Mit einem unterschriebenen Input wird normalerweise eindeutig festgelegt, welchen vorherigen Output (UTXO) man ausgeben möchte. Daran kann man nachträglich auch nichts mehr ändern, zumindest nicht ohne die Signatur zu verletzen.

Anstatt sich auf genau einen Output festzulegen, den man ausgeben möchte, legt man sich mit ANYPREVOUT auf eine Menge an möglichen Outputs fest.

In einem Input steht immer ein eindeutiger Verweis, sozusagen ein Link, auf den Output, der ausgegeben wird (auch Outpoint oder eben Prevout genannt). Vereinfacht gesagt, wird eben dieser Verweis mit ANYPREVOUTnicht unterschrieben. Er kann sich also verändern, ohne dass die Signatur ungültig wird. Damit können einer Transaktion nachträglich Outputs, die ausgegeben werden sollen, zugewiesen werden, sofern die notwendigen Bedingungen dafür erfüllt sind.

Bereits signierte Transaktionen können relativ dynamisch angepasst werden.

Genauer gesagt legt man sich mit ANYPREVOUT auf ein bestimmtes Script fest. Das ist wichtig zu verstehen, denn mit ANYPREVOUTANYSCRIPT treiben wir das Ganze weiter auf die Spitze: Selbst das verwendete Script sowie der Betrag werden jetzt nicht mehr unterschrieben und sind damit ebenfalls variabel. Kleinere Unterschiede im Script spielen also keine Rolle, solange der Output trotzdem ausgegeben werden kann.

ANYPREVOUT: Any previous output, also beliebiger vorheriger Output (APO).
ANYPREVOUTANYSCRIPT: Any previous output with any script, also beliebiger vorheriger Output mit variablem Bitcoin Script (APOAS).

Wozu soll das gut sein? Schauen wir es uns an einem Beispiel an: Eltoo!

LN Symmetry

Da der Name „Eltoo“ ziemlich ungünstig für ein „L2“ Protokoll gewählt ist, wird in letzter Zeit immer häufiger stattdessen der Name LN Symmetry genutzt. Gemeint ist aber der gleiche Mechanismus, den wir uns jetzt endlich genauer anschauen können.

Kehren wir zu Alice und Bob zurück. Die beiden nutzen mittlerweile einen Lightning Channel mit LN Symmetry. Die Verträge (also die vor-signierten Transaktionen) zum Aktualisieren des Zustands im Channel, sind jetzt anders aufgebaut und nutzen einen neuen Mechanismus. Bisher mussten die beiden jeweils den vorherigen Vertrag aktiv entwerten beziehungsweise eine Bestrafung ermöglichen. Mit LN Symmetry ist das nicht mehr notwendig.

Jeder aktualisierte Vertrag wird von den beiden nun mit ANYPREVOUTANYSCRIPT unterschrieben. Diese Signatur kann jetzt an jeden Zustand bzw. Vertrag nachträglich gebunden werden, und die Transaktion bleibt gültig. Die Zustände wiederum sind alle nummeriert und eine Ausgabebedingung ist, abhängig von dieser Nummer, so festgelegt, dass neuere Zustände alte überschreiben können. Das führt dazu, dass der aktuellste, also der „echte“, Zustand immer „das letzte Wort“ hat.

Schauen wir uns das konkreter an einem Beispiel an. Zu Beginn besitzt Alice 5 BTC und Bob nichts, da in diesem Fall nur Alice Geld zur Verfügung stellt. Einige Zahlungen später (Update 3) hat Alice bereits 3 BTC an Bob gezahlt und besitzt jetzt also nur noch 2 BTC. Diese Transaktionen finden natürlich wie bereits besprochen nicht im Bitcoin Netzwerk statt, sondern Alice und Bob unterschreiben sich diese lediglich gegenseitig – es sind eben Lightning Zahlungen.

Alice möchte Bob nun betrügen und einen älteren Zustand veröffentlichen, der für sie von Vorteil ist (z.B. der Zustand nach dem ersten Update, um Bob effektiv 2 BTC zu stehlen). Die erste Update-Transaktion wird jetzt also im Bitcoin Netzwerk veröffentlicht und bestätigt. Noch hat Alice nichts gewonnen, denn das finale Settlement, also das Auszahlen an die beiden Teilnehmer, hat noch nicht stattgefunden. Der gemeinsame UTXO kann nur unter zwei Bedingungen ausgegeben werden:

  1. Nach Ablauf einer zeitlichen Verzögerung mit einer Settlement-Transaktion, die mit ANYPREVOUT unterschrieben wurde. Hier ist die Signatur also auf einen festen Betrag bzw. ein Script, nämlich den jeweiligen Zustand, festgelegt.

  2. Sofortiges Überschreiben mit einer Update-Transaktion, die mit ANYPREVOUTANYSCRIPT unterschrieben wurde und eine höhere Zustandsnummer hat, also aktueller ist.
Vereinfachte Darstellung: Bob bindet das aktuellste Update an und verhindert den Betrugsversuch.

Bob kann also, bevor die Settlement-Transaktion für den Zustand gültig wäre und von Alice veröffentlicht werden könnte, eine neuere Update-Transaktion anbinden und somit den Betrugsversuch verhindern.

Wichtig zu verstehen ist, dass, auch wenn die Signaturen sehr dynamisch einsetzbar sind, die Zustandsnummern in Stein gemeißelt sind. Auch mit ANYPREVOUTANYSCRIPT werden diese nämlich unterschrieben.

Bob hätte nicht zwingend das aktuellste Update 3 dafür nutzen müssen, denn der Zustand nach Update 2 wäre für ihn viel vorteilhafter. Dann hätte aber Alice wiederum die Möglichkeit gehabt, seine Update-Transaktion zu „überschreiben“. Um nicht unnötige Transaktionsgebühren zu verschwenden ist es also attraktiver ehrlich zu sein und direkt den „echten“ Zustand zu veröffentlichen, denn darauf wird es sowieso immer hinauslaufen.

Der aktuellste Zustand kann alle vorherigen überschreiben, weshalb man die alten gar nicht mehr aufbewahren muss. Außerdem braucht es keinen Mechanismus für Bestrafungen mehr!

Einen winzigen Haken gibt es doch noch: Will einer der beiden den Kanal ohnehin schließen, dann kann man es einfach mal mit einem Betrug versuchen. Es gibt schließlich keine Bestrafung mehr und Transaktionsgebühren muss man sowieso bezahlen. Der andere ist dann gezwungen zu reagieren und den aktuellsten Zustand zu veröffentlichen. Hier könnte man dagegen argumentieren, dass solch ein Verhalten für Misstrauen und Rufschädigung sorgt und es deswegen keinen Anreiz dafür gibt. Trotzdem gibt es auch Vorschläge, einen kleineren Bestrafung-Mechanismus für eben diesen Sonderfall einzubauen.

Fazit

Eltoo bzw. LN Symmetry ist ein ziemlich genialer Ansatz um das Verwalten von Lightning Kanälen deutlich zu vereinfachen und skalierbarer zu machen. Zwar funktioniert LN Penalty auch heute schon sehr gut, aber vor allem wenn man viele Kanäle verwaltet kann es sich als mühsam heraus stellen, alle alten Zustände aufzubewahren, gerade wenn es um Backups geht. Auch bei sogenannten Watchtowern, die für viele Nutzer gleichzeitig das Bitcoin Netzwerk nach Betrugsversuchen überwachen, wäre LN Symmetry eine deutliche Verbesserung, da für jeden Kanal eben nur noch ein einziges Update aufbewahrt werden muss.

Die neuen SIGHASH Typen sind mittlerweile seit Jahren, damals noch unter dem Namen „SIGHASH_NOINPUT“ im Gespräch und dem Update steht jetzt eigentlich nur noch die Aktivierung (als Soft Fork) im Weg. BIP-118 ist bereits im Signet (einem Bitcoin Testnetzwerk) aktiviert und wird dort auf die Probe gestellt.

Neben dem angesprochenen Vorteil von weniger Speicheraufwand gibt es noch weitere neue Möglichkeiten, darunter z.B. Channel Factories, die es ermöglichen zu dritt Lightning Kanäle untereinander zu öffnen, ganz ohne Transaktion im Bitcoin Netzwerk!

Wenn euch das Thema weiter interessiert oder es noch offene Fragen gibt, meldet euch doch in unserem Blocktrainer Forum und diskutiert mit anderen aus der Community!