Turbo-Channels für Lightning: Lösen sie das Liquidity-Problem für neue User?

Das Lightning-Netzwerk hat mehrere Probleme mit der Usererfahrung. Die neue Phoenix-Wallet von Acinq beansprucht, diese durch „Turbo-Channels“ zu lösen. Wir schauen uns an, wie es funktioniert, und testen die Wallet.

Am Sonntag hat sich der CoinDesk-Podcast „Late Confirmation“ das Thema Liquidity Management vorgenommen. Wer sich mit dem Lightning Netzwerk beschäftigt hat, weiß, worum es geht – um ein Problem, das den Aspirin-Bedarf der meisten Lightning-User und -Entwickler rapide in die Höhe treibt.

Der Coindesk-Podcast erklärt es so: „Andreas (der bereits Lightning) benutzt, sendet Stephanie eine Zahlung über Lightning entweder durch einen direkten Channel zu ihr oder über eine Route von Zwischenstationen, um Stephanie zu erreichen. Aber wenn ein User branntneu im Lightning-Netzwerk ist, wie bekommt er seine erste Zahlung?“ Wenn jemand noch keine Channels hat, kann er kein Geld empfangen, und selbst dann, wenn jemand einen Channel eröffnet – was eine gewisse Zeit braucht – muss er erst einmal dafür sorgen, dass die Liquidität, die anfangs noch rein ausgehend ist, irgendwie eingehend wird. In unserem Guide, wie man mit einem Lightning-Node Geld empfängt, erfahrt ihr mehr über das Dilemma.

Es gibt, so der Podcast, zwei neue Modelle, um dieses Problem anzugehen. Das eine wird von Phoenix, der neuen Wallet der französischen Lightning-Entwickler Acinq, repräsentiert, das andere von Zap, der Lightning-Wallet von Jack Mallers. Da die Funktion bei Zap bisher nur wenigen ausgewählten Betatestern in den USA zur Verfügung steht, konzentrieren wir uns hier auf Phoenix.

Acinq beansprucht, mit Phoenix die Lightning-Wallet entwickelt zu haben, die man auch seiner Oma empfehlen kann. „Phoenix kümmert sich um alles unter der Haube. Der User wird kaum etwas davon mitbekommen, außer, dass die Zahlungen schneller und günstiger sind“. Die Verbesserung der Usererfahrung, kündet die Webseite an, sei so signifikant, „dass Phoenix es verdient, eine eigene Klasse zu sein.“

Wir werden uns die neue Wunder-Wallet gleich anschauen. Zuerst aber steigen wir in die Theorie ein – welche Probleme löst Phoenix auf welche Weise?

Die Probleme, die Phoenix lösen soll

In dem Blogpost, mit dem Acinq die neue Wallet vorstellt, macht das Unternehmen keinen Hehl aus den Problemzonen von Lightning. In gewisser Weise kritisiert Acinq Lightning in einer Schärfe, die selbst entschiedene Lightning-Zweifler selten erreichen.

Zunächst zählt Acinq einige typische Operationen auf, die User mit einer Bitcoin-Wallet durchführen:

1. Installieren,
2. 0,004 Bitcoin empfangen,
3. 0,001 Bitcoin senden,
4. 0,003 Bitcoin empfangen,
5. deinstallieren und wiederherstellen,
6. die verbleibenden 0,006 BTC senden.

Dies „ist mit einer gewöhnlichen Bitcoin-Wallet trivial,“ konstatiert Acinq, „aber es ist absurd schwierig mit Lightning.“

Der Ärger beginnt beim zweiten Schritt: „Man kann mit Lightning kein Geld erhalten, wenn man keinen Channel hat. Aber man braucht Bitcoins, um einen Channel zu öffnen, richtig? Man kann also keine Bitcoins empfangen, wenn man noch keine Bitcoins hat. Das ist ziemlich ärgerlich.“

Nicht minder problematisch ist die Wiederherstellung der Wallet: Ein Seed stellt zwar die Adressen wieder her, aber nicht die Channels. Und in denen werden in Lightning eben die Guthaben gespeichert.

Acinq behauptet nun, die beiden Probleme gelöst zu haben. Entscheidend sind zwei Methoden: Pay-to-Open löst das Problem mit der eingehenden Liquidität, Peer-Backups das mit den Backups. Sollte beides funktionieren, wäre das tatsächlich ein massiver Durchbruch in der Nutzererfahrung für Lightning.

Was genau meinen die Begriffe?

Pay-2-Open

Eine frisch installierte Phoenix-Wallet hat keine Bitcoins, keine Channels und keine Liquidität. Und doch kann man mit ihr Lightning-Zahlungen empfangen. Ein Video von Acinq demonstriert dies:

Wie zum Teufel ist das möglich? Wer Lightning versteht, vermutet hier vollkommen zu recht schwarze (oder weiße) Magie. Auf dem Firmenblog erklärt Acinq, was hinter der Kulisse abläuft.

Um es zu verstehen, sollte man zunächst wissen, dass es bei Lightning zwei Arten von Channels gibt: Öffentliche und private. Die privaten Channels werden nicht öffentlich bekanntgegeben. Damit eine Zahlung dennoch den Weg zu ihnen findet, enthält eine Zahlungsaufforderung Hinweise darauf, wie die Zahlung zu routen ist. Deswegen sind solche Zahlungsaufforderungen auch relativ lang:

lightning:lnbc114290n1p0z7rt0pp5s9yamhm6wuzhtdecamv2pq356uqsf4ta3dp72jsl7gn45rpx740qdqc2p5x7etwd9uzqurp09kk2mn5xqrrss9qtzqqqqqq9qqqsp56cq9vyjz5mhxrhmedc4e536t4ek8w93yf82v30x4au9s2f22h02srzjqwryaup9lh50kkranzgcdnn2fgvx390wgj5jd07rwr3vxeje0glcll7675kf8s96asqqqqlgqqqqqeqqjqx5pdsc2hhfn4yp3dxefl5jw6ykh6ey72st96fecczeapk4eaf7y5yxw9ttvp8q2ffa4f4n59zasxdlmuczd4wzlrjedm9ll47zjpfccpl8v9v2

Phoenix benutzt nun diese Routing-Hinweise, um dem Sender zu erklären, wie er eine Route findet – selbst wenn es noch gar keine Channels gibt. Dies ist möglich, weil Phoenix nur mit einem Node von Acinq verbunden ist. „Die Phoenix Wallet bildet einen Fake-Channel zwischen dem Acinq-Node und sich selbst, mit einem speziell konstruierten Identifier, und fügt diesen dem Invoice hinzu.“ Die Zahlung weiß also, dass sie zum Knoten von Acinq gehen muss. Sobald sie dort angekommen ist, leitet Acinq sie an Phoenix weiter.

Aber wie kann der Acinq-Node die Zahlung weiterleiten, wenn es gar keinen Channel zwischen ihm und der Phoenix-Wallet gibt? Zunächst einmal weiß der Node, dass der Channel gefälscht ist, weil der Identifier in der Zahlungsaufforderung diese Information enthält. Also schaut der Node, ob es einen anderen Channel zur Wallet gibt. Wenn nicht, greift Pay-to-Open, was Coindesk einen „Turbo-Channel“ nennt.

Das läuft so ab: Der Acinq-Node erzählt der Phoenix-Wallet, dass er eine eingehende Transaktion hat, und schlägt vor, einen Channel zu öffnen. Danach gibt Phoenix dem Acinq Node das sogenannte Preimage. Dieses erlaubt es Acinq, an Stelle der Wallet die Zahlung anzunehmen. Anschließend bildet Acinq einen Channel mit Phoenix, der den Betrag, den der User empfangen wollte, enthält. Das ist ganz schön kompliziert, aber soweit plausibel.

Dabei öffnet nicht der User den Channel, sondern Acinq. Da dafür eine Onchain-Transaktion notwendig ist, bezahlt der Acinq-Node die dafür fälligen Gebühren. Um diese an den User weiterzugeben, verlangt Acinq für die Turbo-Channels eine kleine Gebühr. Mit 0,5 Prozent des erhaltenen Betrages fällt diese nicht nur sehr moderat aus, sondern dürfte bei kleineren Zahlungen bei weitem nicht ausreichen, um die Kosten zu decken.

Peer Backups

Fast noch spannender finde ich die Peer Backups. Wenn man im Ansatz versteht, wie Backups durch Seeds funktionieren, wird man ein sehr großes Vertrauen in sie verspüren – aber auch in keinster Weise glauben, dass man jemals Lightning-Zahlungen durch einen Seed abspeichern kann.

Eine Onchain-Zahlung geht an eine Adresse. Diese ist eine Ableitung aus einem privaten Schlüssel, der wiederum deterministisch – also in einer vorher definierten Abfolge – von einem Geheimnis wie der Seed abgeleitet werden kann. Mit dem Masterkey kann man alle privaten Schlüssel, die die Wallet jemals bilden wird, vorherberechnen. Daher funktionieren Seeds als Backup.

Lightning-Zahlungen dagegen sind Zustände von Channels, die keine solche Verankerung in der Mathematik haben. Daher kann man sie auch nicht durch den Seed rekonstruieren.

Wie Peer Backups dies dennoch schaffen, erklärt Acinq in einem weiteren Post. Die vorherige Wallet von Acinq, Eclair, hat versucht, Google Drive für Backups zu benutzen: Jedesmal, wenn sich der Zustand eines Channels ändert, speichert Acinq eine verschlüsselte Version des Channels in Google Drive, sofern das Feature aktiviert ist. Dieses Backup „funktioniert gut genug“, bringt die User aber in Abhängigkeit.

Ein Fortschritt von diesem Verfahren sind Static Backups. Bei diesen rekonstruiert die Wallet die Guthaben aus der Seed, indem sie die Channels wiederherstellt. Dafür benötigt sie jedoch die Information, mit welchen Peers man ein Backup hat. Daher ist weiterhin bei jeder Zahlung ein Update notwendig. Zudem wird die Rekonstruktion der Wallet alle Channels schließen, was zumindest ein unangenehmer Nebeneffekt ist.

Die Idee bei Phoenix ist nun, statische Backups zu benutzen, „und dazu unsere Peers ein Backup der Channels speichern zu lassen.“ Anstatt Google die Daten zu vertrauen, sollen diese also in der dezentralen Cloud der Lightning liegen. Woher aber weiß ich, wer meine Peers sind, wenn ich die Wallet verloren habe? Und warum sollten meine ehemaligen Peers mir helfen, meine Coins wiederherzustellen?

Die Antwort auf beide Fragen ist einfach: „Der Peer ist immer Acinq.“ Schließlich verbindet sich Phoenix nur mit Acinq. Dementsprechend hat Acinq auch Anreize, zu kooperieren – die Firma möchte ja schließlich das Vertrauen der User und hat selbst Geld in den Channels.

Das Vertrauen kehrt zurück

Die Probleme, die Acinq benennt, sind nahezu identisch mit denen, die ich vorgefunden habe, als ich im Sommer 2018 einen Lightning-Node aufgesetzt habe. Die Lösung, die Acinq dafür entwirft, ähnelt dem, was ich vorausgesehen habe:

Um Geld zu empfangen, benötigt ein User in mehreren Beziehungen Hilfe: Um nicht ständig online sein zu müssen, um die Zahlungsaufforderung weiter zu reichen, um sich vor Verlusten durch betrügerische Schließungen von Channels zu schützen, und um genügend eingehende Liquidität zu erreichen. Es bietet sich an, dass ein Dienstleister diese Aufgaben für den User übernimmt.

Lightning bringt die Abhängigkeit von Mittelsmänner wieder in Operationen zurück, bei denen die Bitcoin-User zuvor autonom waren. Acinq selbst räumt ein, dass Phoenix ein Stück Vertrauen in Acinq wiedereinführt – betont allerdings auch, dass die Wallet weiterhin nicht-treuhänderisch ist, weil das Unternehmen keine Kontrolle über die privaten Schlüssel hat. Dies ist wahr, und sollte es funktionieren, wäre dies ein enormer Fortschritt gegenüber den derzeit eher gängigen treuhänderischen Lightning-Wallets.

Daher schauen wir uns jetzt an, wie es in der Praxis funktioniert.

Phoenix im Test

Der erste Eindruck der Phoenix-Wallet ist hervorragend. Die Wallet startet sofort, und der User muss, anders als bei anderen Lightning-Wallets fürs Smartphone, nicht warten, bis die Wallet mit dem Netzwerk synchronisiert hat. Auch in Sachen Sicherheit hält Phoenix ein vernünftiges Maß. Eine PIN wird nicht verlangt, eine Passphrase ist nicht zu notieren. Die Wallet zeigt lediglich die Meldung an, dass man beides tun sollte. Das Design ist minimalistisch und übersichtlich.

Ich habe dann versucht, mit Phoenix Geld über Lightning zu empfangen, ohne vorher einen Channel zu eröffnen. Also habe ich eine Zahlungsaufforderung gebildet und entweder per Google-Drive auf meinen PC übertragen, um sie bei Electrum und LND einzufügen, oder ich habe sie direkt in andere Lightning-Apps auf dem Smartphone einkopiert: Lightning App, Eclair und Breez.

Leider konnte keine der Wallets die Zahlungsaufforderung begleichen. Ich habe zunächst 10 Euro versucht, bin dann auf 5, 2, 1 Euro und schließlich 50 Cent heruntergegangen. Die Zahlung ist immer gescheitert. Bei LND erhielt ich die Info, dass die Prüfsumme der Zahlungsaufforderung falsch ist, was aber daran lag, dass sie das Präfix „Lightning:“ enthielt. Nachdem ich das entfernt habe, versuchte LND eine Route zu finden, scheiterte aber.

Durch die Hilfe des Phoenix-Supports habe ich schließlich herausgefunden, woran es lag: Die Phoenix-App muss aktiv und im Vordergrund des Smartphones sein, um diese Zahlungen anzunehmen. Es ist also eher unmöglich, mit anderen Wallets auf demselben Gerät zu bezahlen. Bei meinen vorherigen Versuchen auf dem PC ging wohl der Screensaver auf dem Smartphone an, was Phoenix in den Hintergrund gerückt hat. Als ich es nochmal probiert habe und darauf achtete, dass die Wallet im Vordergrund bleibt, hat es endlich funktioniert.

Es war nicht einfach. Aber am Ende demonstriert Phoenix doch, dass das Liquiditätsproblem bei Lightning lösbar ist.