Die Pickhardt-Payments: Für Lightning eine kleine Revolution

Derzeit feiert die Lightning-Community die „Pickhardt Payments“. Diesde sind benannt nach René Pickhardt, einem deutschen Mathematiker und Lightning-Maximalisten. Wir werfen einen Blick darauf: Weshalb werden die Pickhardt-Payments so gerühmt? Und werden sie ihren Versprechungen gerecht?

Dieser Artikel wird nicht einfach werden. Weder für mich, den Autor, noch für euch, die Leser. Ich habe Mühe, die Technik zu verstehen, und noch mehr Arbeit, sie euch verständlich wiederzugeben. Ihr werdet, trotz all meiner Anstrengung, einige Gehirnzellen bemühen müssen, um mir zu folgen. Lightning ist eben kein Sommerspaziergang.

Springen wir direkt ins Thema: Pickhardt Payments. Das wichtigste an diesen Zahlungen ist, dass man durch sie zuverlässig große Summen versenden kann. Wer Lightning kennt, weiß, dass das einen echten Durchbruch verspricht.

René Pickhardt und Stefan Richter aus Leipzig haben die Pickhardt Payments getestet. Das Ergebnis war so phantastisch, dass René auf Twitter frohlockt: „Ratet mal, wer eben von Stefan zwei GROSSE (!) Bitcoin-Zahlungen über Lightning empfangen (und zurückgesendet) hat? Die erste Zahlung: 0,3679 BTC, die zweite Zahlung: 0,286 BTC. Teamwork lässt Träume wahr werden!“

Guess who received (& send back) 2 LARGE (!) mainnet #Bitcoin payments from @stefanwouldgo over the #LightningNetwork!

1st payment: 0.3679 BTC (345 parts minSplitSize: 10k sats)

2nd payment: 0.286 BTC (80 parts minSplitSize: 100k sats)

Teamwork makes the dream work!

1/4 https://t.co/daShPKMQbC

— Rene Pickhardt (@renepickhardt) July 24, 2021

Pickhardt Payments, das wissen wir nun, funktionieren. Und, das wissen wir auch: sie werten Lightning gewaltig auf. Denn bisher waren Zahlungen mit dem Offchain-Netzwerk ab einer gewissen Größe ein ziemlicher Murks: Man klappts, mal nicht, warum und weshalb weiß man als Nutzer in der Regel nicht.

Wenn es René wirklich gelungen wäre, das zu ändern, wenn man in Zukunft sagen wir 2000 Euro ganz bequem und zuverlässig durch Lightning routen könnte – dann hätte der deutsche Mathematiker einen bleibenden Fußabdruck in die Geschichte Bitcoins gesetzt.

Aber kommen wir zu den Fragen, die uns auf den folgenden Seiten umtreiben: Wie funktioniert es? Und warum? Was machen die Pickhardt-Payments anders? Und was hindert das Lightning-Netzwerk daran, die Pickhardt Payments sofort umzusetzen? Woran hängt es? Was schließlich hat das alles mit der Basisgebühr zu tun?

Auf ins Getümmel!

Ein anderes Lightning-Netzwerk ist möglich

Wir kommen nicht umhin, ein Paper zu lesen, in dem René und Stefan die Zahlungen beschreiben. Das Paper ist ziemlich har(d)t: Es ist gespickt mit Fachwörtern, Formeln und Zahlen, und es drückt sich allgemein, satzbaumäßig und so, nicht eben vorbildhaft lesefreundlich aus.

Aber ist Kernaussage ist klar: Es sollte grundsätzlich möglich sein, mit Lightning zuverlässig hohe Beträge zu versenden. All das, was wir bisher über die Beschränkungen von Lightning geglaubt haben, ist falsch: Ein Irrtum, der wenig mit Lightning, aber viel mit falschen Algorithmen zu tun hat.

Die Krux mit großen Zahlungen

Man muss zumindest im Groben verstehen, wie Lightning funktioniert: Die Knoten des Netzwerks verbinden sich mit Payment-Channels zu einem Mesh-Netzwerk. Zahlungen können von Knoten zu Knoten springen und damit auch Ziele erreichen, die im Netzwerk weit entfernt sind. Das etwa ist die Grundarchitektur.

Allerdings stößt man dabei immer wieder auf Probleme und Beschränkungen. Das beginnt beim eigenen Knoten: Um 0,4 Bitcoins zu versenden, brauche ich nicht nur ein Guthaben von 0,4 BTC. Ich brauche diese Summe als ausgehende Liquidität. Umgekehrt reicht es nicht, wenn der Empfänger einfach eine Wallet und einen Payment-Channel hat: Er braucht dieselbe Summe als eingehende Liquidität.

Und als wäre das nicht schon heikel genug, brauchen alle Knoten, die zwischen Sender und Empfänger stehen, dieselbe ein- und ausgehende Liquidität. Es reicht nicht, dass die Garage bei mir und bei dir groß genug für mein Fahrzeug ist – die Straße muss es auch sein.

Das ist bei kleinen Beträgen nicht weiter wichtig. Ein Roller kommt überall durch. Sobald der Betrag, den wir durchs Netz zwängen wollen, aber wächst, wird es immer schwieriger, Wege zu finden, die breit genug sind. Die Fahrer von Schwertransportern kennen das.

Ein Paper, an dem René im vergangenen Jahr mitgeschrieben hat, zeigte, dass die Wahrscheinlichkeit, eine Zahlung erfolgreich durch Lightning zu bringen, mit steigender Höhe abnimmt. Das war für viele recht enttäuschend, für manche Spötter aber hoch erfreulich: Das vielgerühmte Lightning-Netzwerk ist unzuverlässig. Was taugt so etwas als Zahlungssystem?

Das ist das Problem. Aber zum Glück hat fast jedes Problem auch eine Lösung.

Wie Sand durch ein Sieb rieseln

Sehr vielversprechend für große Zahlungen und enge Wege sind die Multi-Path-Payments (MPP), zu deutsch: Zahlungen über mehrere Wege. Diese wurden im letzten Jahr durch lnd 0.10 eingeführt.

Konzeptionell sind MPP einfach: Sie zerschlagen eine Transaktion in viele kleine Stücke. Der Sender schickt diese Splitter einzeln durchs Netzwerk, und der Empfänger setzt sie dann wieder zusammen. MPP sind privater, fungibler und, vor allem: viel flexibler als klassische Lightning-Zahlungen.

Man kann es sich wie ein Sieb vorstellen: Ein grobes Korn Salz bleibt hängen. Selbst ein Gramm kann zuviel sein. Aber feines Salz rieselt durch, Kilogramm um Kilogramm. MPP sind eine ziemlich elegante Lösung.

Allerdings hinkt die Wirklichkeit derzeit noch der Theorie hinterher. Es ist weiterhin schwierig, mit Lightning höhere Beträge zu versenden. Trotz MPP.

Und damit wären wir bei René und seinen Pickhardt Payments.

Was die bisherigen Algorithmen falsch machen

René hat während der letzten Monate auf diesen Fragen herumgekaut: Warum ist Lightning, trotz MPP, so ineffizient? Was machen wir falsch?

Also hat der Mathematiker in den Algorithmus geschaut, durch den die Wallets eine Route zum Empfänger suchen. An sich wäre das relativ einfach: Es ist eine Art von Network Flow Problem. Wer das nicht kennt, ist in breiter und guter Gesellschaft. Ihr müsst nur wissen, dass solche Network Flow Probleme gelöst bzw. lösbar sind.

Daher versuchen die Lightning-Entwickler auch schon ein Weilchen, das Routing im Lightning-Netzwerk als Network Flow Problem zu formulieren. Doch ihnen ist das bisher nicht gelungen. Erst als René und Stefan erkannt haben, dass es sich um ein „Min Cost Flow Problem“ handelt – ein eher seltenes Problem dieser Gattung -, gelang es.

Allerdings müsste man dafür die konkreten Guthaben aller Knoten kennen, sowohl die eingehende als auch die ausgehende Liquidität. Da das Lightning-Netzwerk aber bewusst intransparent designt wurde, kennen die Wallets eben dies nicht: Sie wissen um die initiale Liquidität anderer Channels, aber nichts über die aktuelle. Sie wissen, mit wie viel Bitcoin der Payment Channel initial gebaut wurde, aber nicht, wie viele aktuell nach außen und nach innen weisen. Ein Channel kann riesig sein, aber wenn die ganze Liquidität in die falsche Richtung weist, ist er für den Sender wertlos.

Die Wallet weiß, wieviel ein Node zwischen ihr und dem Empfänger routen könnte. Sie kann aber nur raten, wieviel er tatsächlich routen kann. Der Liquiditäts-Graph von Lightning existiert durchaus – allerdings kennt ihn keiner. Man kann nur mehr oder weniger gut schätzen und raten.

Also gehen die Wallets nach der Methode Versuch-und-Irrtum vor: Sie schätzen die Liquidität, probieren Wege aus, und wenn es nach ein paar Mal nicht geklappt hat, brechen sie ab und spucken eine Fehlermeldung aus. Was für viele User so kryptisch wie frustrierend endet.

Dabei berücksichtigen die Wallets aber nicht nur die mögliche Liquidität. Sie kalkulieren auch die Gebühren mit ein, die die Knoten zwischen Sender und Empfänger verlangen, um eine Zahlung durchzulassen. Die Wallets versuchen natürlich, zu hohe Gebühren zu vermeiden.

Das hat, erklärt das Paper von René und Stefan, die unerwünschte Konsequenz, „dass viele Zahlungen eine große Anzahl günstiger, aber unzuverlässiger Pfade auszuprobieren, bevor sie aufgeben, anstatt einen leicht teureren, aber sehr viel zuverlässigen Pfad.“

Und schon haben wir einen Ansatz, wie es besser gehen könnte.

Die perfekte Welt in einer Formel

René beginnt mit dem idealen Lightning-Netzwerk: Ein Netzwerk, in dem alle konkreten Guthaben bekannt sind. Hier wäre es einfach, einen zuverlässigen und idealen Pfad zu finden.

Dann fügt er eine Unbekannte ein: die konkreten Guthaben. Wenn man sie nicht kennt, kann man nur raten und irren. Das macht die Lösung der Gleichung schwierig. Aber nicht unlösbar. Nachdem René das Problem formuliert und simuliert hat, erhielt er ein vielversprechendes Ergebnis: „Nur in 5 Prozent aller Zahlungspaare ist der Max-Flow kleiner als der maximale Betrag, den ein Knoten lokal versenden und ein anderer lokal empfangen kann.“

Das bedeutet: Nur ein minimaler Anteil Zahlungen muss scheitern, weil es zwischen Sender und Empfänger an Liquidität mangelt. So gut wie jeder Knoten ist prinzipiell in der Lage, so viel zu versenden, wie er an ausgehender, und so viel zu empfangen, wie er an eingehender Liquidität hat.

Das allerdings widerspricht der praktischen Erfahrung mit Lightning fundamental. René hat ausgerechnet, dass das Netzwerk sehr viel besser ist, als es aus Perspektive der Wallets aussieht.

Aber woran hakt es in der praktischen Wirklichkeit noch? Und wird es möglich sein, die Mathematik in Praxis zu übersetzen?

Wenn das Modell auf die Wirklichkeit trifft

Ein wesentliches Hindernis sind Gebühren. Wenn ein Knoten eine Zahlung weiterleitet, kann er dafür eine Gebühr verlangen. Dies ist im echten Leben unvermeidbar. Wie sollte er auch sonst den Betrieb seines Knotens finanzieren? Langfristig kann Lightning nicht als Wohltätigkeitsveranstaltung laufen.

In ihrem Modell haben René und Stefan keine Gebühren berücksichtigt, weil man das mit Modellen so macht: Man vereinfacht die Wirklichkeit. In der Praxis kann sich eine Wallet das freilich nicht erlauben: Wenn sie die Gebühren ignoriert, läuft der User Gefahr, zum Opfer von anderen Knoten zu werden, die die Gebühren beliebig hochschrauben können.

Vor allem bei Multi-Path-Payments kann dies rasch teuer werden: Lightning-Knoten berechnen zwar in der Regel in Relation zum Betrag, zum Beispiel 0,01 Prozent. Aber oft gibt es eine Basisgebühr, und wenn jeder Splitter, den der Sender durchs Netzwerk jagt, diese bezahlt, läppert sich rasch gut etwas zusammen.

Wenn man vom Modell ohne Gebühr in die Wirklichkeit geht, wird die ganze Formel wieder ein Stückchen schwieriger. Doch noch immer nicht unlösbar, erklären René und Stefan im Paper: „Wir haben beobachtet, dass bei einem Flow, der eine obere Grenze der gesamten Gebühren beinhaltet, die Wahrscheinlichkeit einer erfolgreichen Zahlung ebenso hoch sein wird wie in unserem Modell.“

Warum und Wieso wird an dieser Stelle viel zu fachmännisch: Die Formel sei zwar „NP-Schwer“ – das ist ein ziemlich verwirrender Fachbegriff der theoretischen Informatik – aber „konvex“ – erneut eine Beschreibung, mit der Nicht-Mathematiker in diesem Kontext wenig anfangen können. Aber es bedeutet, dass es erprobte Verfahren gibt, um die Formel zu lösen.

Allerdings bleibt ein Haken: „Wenn die Basis-Gebühr größer ist als die proportionale Unit Flow Cost“, schreiben René und Stefan, dann sei die Funktion nicht länger konvex. Und wenn ein NP-schweres Problem nicht mehr konvex ist, dann wird es „stark NP-schwer“. Das geht dann schon in Richtung unlösbar. Es ist zumindest im Rahmen eines vernünftigen Aufwandes an Rechenkraft und Zeit kaum mehr zu lösen.

#zerobasefee

Ihr versteht? Zumindest grob und vage? Lightning könnte wundervoll funktionieren. Man könnte problemlos zuverlässig große Summen versenden, sogar dann, wenn die Zwischenknoten Gebühren verlangen und man diese Gebühren berücksichtigt.

Wäre da nicht die Basisgebühr. Denn die wanzt sich in die Formel ein und macht sie kaum mehr lösbar. Es ist dieses eine, vermaledeite Detail am Lightning-Netzwerk, das die ganze Magie zerstört.

Was also tun? Einsehen, dass die brillantklare Mathematik auf den letzten Meter auf der Zielgeraden an der trüben Wirklichkeit scheitert?

René und Stefan wagen stattdessen den Versuch, die Wirklichkeit an das Modell anzupassen. Sie schlagen vor, die Basis-Gebühr auf Null zu setzen. „Es kommt uns vor, als sei sie eher adhoc und willkürlich gesetzt worden und übe keine signifikante Bedeutung für das Lightning Netzwerk-Protokoll aus.“ Angesichts von Multi-Path-Payments sei die Basisgebühr generell extrem hinderlich, da sie Multi-Path-Payments in jedem Fall viel zu teuer macht.

Für Nodes könnte es, führen die beiden aus, sogar lukrativ werden, die Basisgebühr fallen zu lassen: Wenn es üblich werde, die Routen mit der neuen Methode zu berechnen, werden Knoten, die dies nicht machen, nicht länger beim Pfadfinden berücksichtigt. Wer eine Basisgebühr erhebt, disqualifiziert sich selbst, wer sie aufhebt, profitiert vom Weiterleiten von Transaktionen.

An sich spricht die Spieltheorie dafür, dass René und Stefan gegen die Basisgebühr gewinnen. Daher haben sie den Code veröffentlicht, um die Basisgebühr auf Null zu senken. Diesen bewerben sie unter dem Hashtag #zerobasefee.

Und so, wie es aussieht, kommt es gut an: Rund ein Viertel der Channels im Lightning-Netzwerk haben die Basisgebühr bereits auf Null gesenkt. Ist noch ein Stück bis 100 Prozent, sieht aber schon mal gut aus.