Lightning Zahlungen ohne Internetverbindung – So funktioniert ein Offline Point-Of-Sale

Eine Grundvoraussetzung für eine Teilnahme am Lightning-Netzwerk ist eigentlich die Verbindung zum Internet. Für die meisten Personen sollte das im Zeitalter von Smartphones und 5G kein Problem darstellen. Doch es gibt Einsatzgebiete, in denen es nicht trivial ist eine Internetverbindung aufzubauen. Wie das Lightning Netzwerk grundsätzlich funktioniert erklären wir hier.

Offline-Zahlungen

Ein Beispiel dafür könnten Point-Of-Sale-Geräte, wie Supermarkt-Kassen, sein, die aus Kosten- und Sicherheitsgründen nicht internetfähig sind. Die Möglichkeit ein Empfänger-Gerät offline zu halten, vermindert die mögliche Angriffsfläche bedeutend.

Eine schnelle Überlegung würde dazu führen, dass Key-Send Payments an einen Node theoretisch möglich sind, ohne ein Invoice zu erstellen. Das Problem dabei ist, dass es dem Sender nicht möglich ist, zweifelsfrei zu beweisen, dass er die Zahlung gesendet hat und diese angekommen ist.

Genau zu diesem Thema haben sich Adrian Pauli und Nicola Roten von Puzzle.ch im Zuge ihrer Bachelorarbeit Gedanken gemacht. Wie ist es möglich ein System zu designen, bei dem ein PoS-Gerät offline ist und gleichzeitig eine Zahlung an einen seperaten Node annimmt?

Das Design

Der Versuchsaufbau via puzzle.ch

In ihrem Blogpost zum Thema erklären sie sehr anschaulich wie dies funktioniert. In ihrem Fall ist das PoS-Gerät ein Bier-Hahn, der Bier ausgibt sobald ein Lightning Invoice bezahlt wurde. Dieser ist nicht mit dem Internet verbunden.

Möglich wird die Bezahlung über den Einsatz eines zwischen dem PoS-Gerät und Empfänger-Node geteiltem Geheimnis sowie einem “Deputy Node” . Letzterer ist ein “Fake-Node”, der in Wirklichkeit nicht existiert, sondern nur als End-Empfänger der Onion-Route dient. Dabei stellt der eigentliche Empfänger-Node das vorletzte Glied der Onion-Route dar, welcher, sobald die Zahlung bei ihm angekommen ist, das Preimage decodiert.

Ein Lightning Invoice besteht dabei aus

  • Öffentlichem Teil (Netzwerk, Zahlungsbetrag)
  • Geheimen Teil (Zeitpunkt der Erstellung, Empfänger, Expiry, Memo, Route, Preimage und Backup Adresse)

Der Geheime Teil des Invoices ist signiert und nur für den Empfänger und Sender einsehbar.

Das Preimage als Teil des Invoices besteht dabei aus einem Hash aus dem geteilten Geheimnis, einer zufällig generierten Preimage-Nonce sowie dem Zahlungsbetrag des Invoices. Die Werte für Preimage-Nonce und der Zahlungsbetrag werden per “deputy payment processing” über Onion-Routing an den Empfänger-Node gesendet. Gemeinsam mit dem geteilten Geheimnis kann der Empfänger-Node also das Preimage entschlüsseln und die Preimage-Nonce mit der Preimage-Nonce aus dem DPP Teil des Invoices vergleichen.

Sobald dieser Vergleich erfolgreich ist, kann der Empfänger-Node die Zahlung entgegennehmen und im Gegenzug das Preimage mit dem Sender teilen. Dieses Preimage wird dem Offline-PoS-Terminal mitgeteilt und dieses vergleicht es mit dem von ihm während der Erstellung des Invoices ursprünglich gewählten. Ist dieser Vergleich erfolgreich, war die Zahlung erfolgreich.

Das Ganze klingt erst einmal sehr kompliziert, doch 99% dieses Aufwands läuft automatisch ab. Im Zuge des Blogposts haben die beiden ein Demo-Video hochgeladen, das zeigt wie ein Invoice bezahlt wird und danach die Zahlungsbestätigung in Form des Preimages gezeigt wird.

Um Zahlungen dieser Art möglich zu machen, haben die beiden ihre eigene Version des Zap Wallets kompiliert, die bereits Support für Offline-Zahlungen hat. Ebenso haben sie einen offiziellen Pull-Request für die LN-Spezifikation eingereicht.

Noch mehr

Dies ist erst der erste von 3 Teilen ihrer Arbeit, den die beiden in Form eines Blogposts geteilt haben. In den nächsten Schritten soll es darum gehen, was passiert, wenn der Zahlende offline ist, sowie um “Offline Terminal Device Data Transmission”. Wir sind gespannt, was sich dahinter verbirgt. Das Potential von Lightning als programmierbares Geld ist noch lange nicht ausgeschöpft.

Schreibe einen Kommentar