Gute Energien und konstruktive Offenheit

Am vergangenen Wochenende fand die Lightning-Konferenz statt. Die Atmosphäre war, wie man hört, phantastisch; inhaltlich ging es technisch in die Tiefe. Keine Baustelle und kein Problem blieb unerwähnt – aber es scheint für alles eine Lösung in Aussicht zu stehen. Daneben gab es natürlich auch einige spannende Ankündigungen.

Ich glaube, Enthusiasmus und Ernüchterung sind die beiden Worte, die die Lightning Konferenz in Berlin am besten beschreiben. Ich war nicht da, sondern habe mir meine Eindrücke vor allem über Twitter und das Video des Livestreams des ersten Tages zusammengestückelt. Verpasst habe ich dabei natürlich die Atmosphäre, die für viele Besucher und Teilnehmer überwältigend gewesen muss.

“TLC2019 war zu schnell vorbei. Jeder, mit dem ich gesprochen habe, versucht, etwas aufregendes zu machen, und ich habe das Gefühl, kaum an der Oberfläche gekratzt zu haben”, twitterte etwa Rusty Russell, Blockstreams C-Lightning-Enwickler. Und der Podcaster Stephan Livera sagte, schon am Anfang der Veranstaltung: “Das ist eine Konferenz, an die wir in den kommenden Jahren zurückdenken werden”.

Die Stimmung muss großartig gewesen sein; die Vorträge gingen tief und waren sehr auf die Technik fokusiert, während am Rande zahlreiche Geräte vorführten, was Lightning kann: Die obligatorischen Bier- und Kaffeeautomaten, dazu Computerspiele, E-Roller und andere Maschinen, bezahlbar mit Lightning, für ein paar Satoshi. Man konnte das Zahlungsnetzwerk auf der Konferenz anfassen, und wer bei den Workshops mitgemacht hatte, konnte sich etwa ein Verkaufsterminal für die Lightning-Akzeptanz basteln.

Twitter schäumt förmlich vor Begeisterung. Fodé Dio aus Senegal: “Ich bin so inspiriert von der LNconf, dass ich mir wünsche, sie wird das nächste mal in Dakar stattfinden.” Oder Simon Lutz: “Dieses Wochenende muss in Erinnerung bleiben. Die positive Energie, die überall herrschte, ist mit Worten nicht zu beschreiben. Danke für die großartigen Vorträge, Gespräche und Demos. Jeder von euch gibt mir so viel Hoffnung für die Menschheit.” Und Igor Berezovsky: “LNconf war die beste Konferenz aller Zeiten.”

Pfadfinder und Liquiditätsprovider

Es muss also aufregend gewesen sein. Wir widmen uns hier aber den Vorträgen. Deren Niveau war tatsächlich sehr hoch. Besonders auffällig ist die Ehrlichkeit, mit denen die Sprecher mit den Schwachstellen von Lightning umgehen. Es gibt noch eine Menge Baustellen, und das wird nicht schöngeredet, sondern gnadenlos offengelegt, aber immer aus einer konstruktiven Perspektive und mit der Gewissheit, dass jedes Problem seine Lösung finden wird.

Ein grundsätzliches Problem ist die Pfadfindung. Es steckt im Kern von Lightning: Wie schafft es eine Wallet, eine Route zu finden, um eine Transaktion über mehrere Channels ans Ziel zu bringen? Um die beste Route zu finden, muss die Wallet die Topologie des Netzwerks herunterladen. Da sie aber nicht die konkrete Liquidität in den einzelnen Kanälen kennt, kann eine Zahlung auch steckenbleiben, obwohl die Wallet meint, ein Pfad würde funktionieren. Daher braucht es oft mehrere Anläufe, um eine Zahlung zu ihrem Empfänger zu bringen. Das dauert, wie Rusty Russell klagt, oft viel zu lange. Das ist nicht nur offensichtlich störend für den User, sondern reisst auch Sicherheitslücken auf, die ein Angreifer ausnutzen kann. Rusty twittert: “Weniger als 5 Sekunden wäre ein gutes Ziel.” Es gibt mehrere Ideen, wie man dies erreicht.

Mit demselben Thema beschäftigt sich sein Kollege Christian Decker. Er hat untersucht, wie viele Versuche Zahlungen brauchen. Dazu hat er sich von seinem C-Lightning-Node die Netzwerktopologie exportiert und beliebige Zahlungen von zufälligen Nodes ausprobiert. Die Resultate sind “in keiner Weise optimal”, meint er unverblümt, “ich will euch damit aber nicht erschrecken.” Gerade mal ein bißchen mehr als ein Drittel der Zahlungen findet auf den ersten Versuch eine Route. Mehr als die Hälfte der anderen findet überhaupt keinen Pfad, was vielleicht daran liegt, dass die Nodes offline sind oder sie die Info gespeichert haben, dass sie nicht erreichbar sind und es gar nicht versuchen. “Wir werden sehen, wie sich das über die Zeit entwickelt.” Da man bei diesen Fällen nicht viel machen könne, konzentriert sich Christian Decker auf die restlichen Versuche.

Von diesen finden 66 Prozent auf den ersten Versuch einen Pfad, “das ist ermutigend”. Allerdings benötigen die anderen mehrere Versuche. 90 Prozent der Zahlungen, so ein Fazit von Christian, kommen mit vier Versuchen durch, was maximal 30 Sekunden dauert. Aber etwa fünf Prozent brauchen auch 3 Minuten oder länger. All das ist noch weit von dem entfernt, wie es sein sollte, “aber die gute Nachricht ist, wir agieren erst an der Basis, und die Zahlen werden sich verbessern,” verspricht Christian Decker, “wir haben bereits Ideen, wie wir es beschleunigen können, etwa indem wir die Pfadfindung parallelisieren.” Lightning steht eben trotz allem noch in seiner Kindheit.

Auch Rene Pickhardt hat sich am zweiten Tag mit dem Finden eines Pfades auseinandergesetzt. In seiner Präsentation hat er dabei verschiedene Strategien vorgestellt.

Ein Teil der Problematik, eine Route zu finden, ist die Liquidität. Die Channels, die das Lightning-Netzwerk verbinden, enthalten bestimmte Beträge an ein- und ausgehender Liquidität. Wenn eine Zahlung zu groß ist, wird es für sie schwierig, sich durchs Netzwerk zu pressen. Daher steigt die Gefahr, steckenzubleiben oder viele Anläufe zu brauchen, mit der Größe einer Zahlung. Eine Lösung dafür stellt Connor Frommknecht von Lightning Labs vor: AMP – kurz für Atomic Multi-Path Payments – bricht eine Transaktion in mehrere Teile auf, die dann getrennt voneinander durchs Netzwerk gesendet werden. So kann die Liquidität besser dossiert werden und es stehen mehr Routen zur Option. Damit würde AMP eines der Kernprobleme von Lightning entschärfen.

Verwandt damit sind die Gebühren. Denn um zum Ziel zu gelangen, muss eine Transaktion durch die Channels der sichtbaren Lightning-Knoten wandern. Diese versorgen das Netzwerk mit Liquidität. Dafür bezahlen sie indirekte Kosten – die Bitcoins könnten sicherer verwahrt werden oder mehr Erträge erwirtschaften. Daher sollten sie für diesen Service auch bezahlt werden. Allerdings sind die Transaktionsgebühren in Lightning derzeit so gering, dass sie in der Regel nicht einmal die Kosten für die Onchain-Transaktionen der Channelbildung aufwiegen. Rusty Russel schlägt deswegen vor, die Grundkonfiguration so zu ändern, dass die Gebühren höher werden. Bitcoin habe sich verändert, und so werde sich auch Lightning verändern.

Nicht jeder findet diese Idee gut, etwa der Lightning Labs CTO Olaoluwa Osuntokun. Ihm ist zwar klar, dass auch Lightning einen Gebührenmarkt brauchen wird, um nachhaltig zu sein, aber er meint nicht, dass die Entwickler diesen steuern sollten.

Warum User-Interface und User-Erfahrung zwei ganz verschiedene Dinge sind …

Eine weitere Baustelle ist die Benutzererfahrung. Einige der Sprecher hatten eine wahre Freude daran, den Lightning-Wallets vorzuhalten, wie schlecht sie sind. Etwa Will O’Beirne. Er zeigt Screenshots von mehreren Lightning-Wallets, etwa die Lightning App oder Eclair. “Sie sehen hübsch aus und wirken auf den ersten Blick einfach und geradlinig. Aber das ist nicht die Usererfahrung. Ein schickes Interface kann nicht über eine schlechte Usererfahrung hinwegtäuschen.” Und die ist oft grottig, etwa wenn man versucht, neue User ins Netzwerk zu bringen: Zuerst schreibt der Newbie die Seed Phrase auf (15 Minuten), dann synchronisiert die App (15 Minuten), danach schickt man ihm ein Guthaben (30 Minuten), schließlich öffnet er den Channel (nochmal 30 Minuten). “Es dauert Stunden. Das ist ungünstig, weil die Leute von Lightning erwarten, dass es schnell geht.”

Die gute Nachricht ist auch hier: Man kann vieles relativ einfach besser machen. Warum, fragt O’Beirne, nutzt man nicht die Zeit, bis die App synchronisiert hat, um das Backup aufzuschreiben und die Funding-Transaktion zu versenden? Er schlägt auch vor, in diesen 15 Minuten den User darüber zu informieren, wie er einen guten Channel aufsetzt. Meist haben User – vor allem Neulinge – davon nicht die geringste Ahnung. Eine Wallet sollte dem User daher empfehlen, einen Channel mit einem “guten Routing Node” – etwa von 1ml, Bitrefill, Acinq und so weiter – zu knüpfen, und auch mehrere Channels zu unterhalten, um nicht abhängig von einem Node zu sein.

Über dasselbe Thema hat auch Fabrice Drouin von Acinq geredet. Auch er lässt sich darüber aus, dass das Onboarding neuer User Kopfschmerzen versursache: Wallet runterladen, Bitcoins empfangen, Channel aufmachen, Bitcoins versenden – und selbst nach all dem kann man noch immer nichts empfangen. Und überhaupt – wie ist das mit dem Backup? Dass Zahlungen dazu noch steckenbleiben können, macht es nicht besser. Keine noch so schicke Oberfläche kann das ändern.

Was aber etwas ändert, ist die die Phoenix-Wallet, die Drouin auf der Konferenz vorstellte. Per Video zeigte er, wie mit ihr Onboarding in drei Minuten abgeschlossen ist. “Phoenix”, twitterte Dourice später, “enthält neue Features, die viele der derzeitigen UX Probleme mit Lightning lösen: das einfache Onboarding, kein Channel Management, ein einheitliches Guthaben, aber transparente onchain/offchain Zahlungen, ein einfaches Backup per Seed – und all das noch immer, ohne Treuhänder zu sein.” Klingt extrem gut. Da die Wallet derzeit noch nicht veröffentlicht ist, ist nicht klar, wie Acinq das macht. “Es fühlt sich wie Magie an, oder? Wir werden in einigen Blogposts erklären, wie es funktioniert.”

Mindestens ebenso aufregend ist die Nachricht, dass die Lightning-Integration in Electrum kurz vor der Vollendung steht. Sie ist, erklärt Electrum-Entwickler Thomas Voegtlin, bereits im Master Branch, aber noch nicht veröffentlicht. Für Electrum ist Lightning eine ordentliche Herausforderung. Das Backup, die Liquidität, die Tatsache, dass User nicht immer online sind – diese typischen Probleme sind viel leichter zu lösen, wenn man eine Treuhand-Wallet hat oder, zumindest, einen zentralen Server. Da Electrum aber weder das eine noch das andere hat, wird es schwieriger. “Wir haben die Entwicklung vor 18 Monaten begonnen und hätten nicht gedacht, dass es so lange braucht. Lightning macht mittlerweile, ohne die GUI, ein Drittel des Electrum-Codes aus.”

Die Integration ist zwar noch nicht veröffentlicht, aber Voegtlin rückt mit ein paar Details heraus: Die Channels werden privat sein, eine Electrum-Wallet wird also keine Zahlungen routen und damit kein aktiver Node im Netzwerk sein; wenn Lightning aktiviert ist, wird es eine zweite Wallet-ID geben, und die Guthaben onchain und offchain werden getrennt angezeigt. Die User sollten sich bei einem Watchtower anmelden, “weil wir nicht erwarten können, dass sie die ganze Zeit online sind.” Dabei können sie entweder selbst einen Watchtower aufsetzen oder den Service eines anderen benutzen. Eventuell, könnte man hier spekulieren, können sich Electrum-Server langfristig etwas dazuverdienen, wenn sie auch zum Watchtower werden.

Nur ein Teil des Ganzen …

Es gäbe, natürlich, noch viel mehr zu erzählen, allein vom ersten Tag. So haben Rusty Russell und Christian Decker etwa einen Plugin-Manager für C-Lightning vorgestellt; Rusty hat auch über einen neuen Invoice-Mechanismus gesprochen, der es erlauben soll, auch wiederkehrende Zahlungen zu verarbeiten. Olaoluwa Osuntokun hat über APIs und Maccaroons der Lightning-Nodes gesprochen, Elizabeth Stark, CEO von Lightning Labs, hat im Interview auf der Bühne darüber erzählt, wie sich das Ökosystem langfristig entwickeln soll. Auf dem Merchant Panel berichtet etwa der Chef von Fold, dass Lightning bereits einen großen Teil der Zahlungen ausmacht und seine App vollständig auf onchain-Transaktionen verzichten kann. Und noch vieles mehr.

Aber wir kommen an dieser Stelle zum Ende. Wer mehr über die Lightning-Konferenz wissen will, sollte sich unbedingt die Video dazu anschauen.