Lightning Grundlagen: Was sind LNURL und BOLT12?

Das Lightning Netzwerk (LN) ist ein vielversprechender Payment-Layer, um das Bitcoin-Netzwerk hinsichtlich Transaktionsgeschwindigkeit zu skalieren und dabei die Transaktionskosten zu reduzieren. Oder einfacher gesagt, um Bitcoin auch für tägliche Zahlungsvorgänge besser nutzbar zu machen. Zu seinem Startschuss im März 2018 war es relativ schwierig ein Teil des Netzwerks zu werden und Gelder darüber zu versenden. Im Laufe der vergangenen Jahre wurde das LN jedoch immer nutzerfreundlicher und wuchs infolgedessen auch stetig an. Gleichwohl gibt es noch immer einige Kritikpunkte an der Benutzerfreundlichkeit des Lightning Netzwerks, die es zur vollständigen Massentauglichkeit noch zu lösen gilt. Eines der Hauptprobleme ist beispielsweise die Notwendigkeit, dass man als Anwender für jede Zahlung, die man erhalten möchte, eine eindeutige Rechnung (en. invoice) erzeugen muss, damit das Gegenüber diese bezahlen kann. In der Praxis führt dies zu einigen Hürden, die der Nutzererfahrung (UX) leider nicht zuträglich sind. Mit LNURL und BOLT12 gibt es jedoch bereits gute Lösungen, für einige dieser Probleme. Wir möchten euch diese in diesem Beitrag kurz und knapp näherbringen.

Was ist LNURL?

LNURL ist ein Kommunikationsprotokoll, das einige der UX-Probleme, die das Lightning Netzwerks mit sich bringt, beseitigt. Es besteht aus mehreren Unterprotokollen, die die Kommunikation zwischen Lightning-Wallets und anderen Anwendungen und Diensten vereinfachen und spezifischen Anwendungsfällen dienen. Die wichtigsten Sub-Protokolle bzw. Funktionen sind LNURL-pay, LNURL-withdraw, LNURL-auth und sogenannte "Lightning Adressen". Alle Anfragen und Antworten bei LNURL werden über das bekannte HTTP-Protokoll abgewickelt, weswegen es die Verwendung eines Webservers erfordert.

LNURL-pay

Wie eingangs bereits erwähnt, muss ein Zahlungsempfänger im LN zwangsläufig eine Rechnung an den Sender übermitteln, damit dieser den Zahlungsvorgang einleiten kann. Jede dieser Rechnungen muss individuell und speziell für diesen Zahlungsvorgang generiert werden. Ein einfaches "Hey hier ist meine IBAN oder meine PayPal-Adresse, bitte überweise mir das Geld", wie man es aus dem Alltag kennt, ist so leider nicht möglich. In der Praxis können deswegen auch keine statischen QR-Codes als Spendenadressen für Hilfsprojekte, Content Creator oder Straßenmusiker erzeugt werden, an die Menschen einfach Zahlungen senden können.

Mithilfe von LNURL-pay ist es nun jedoch möglich, dass eine Lightning-Wallet einen Server über einen statischen QR-Code anpingen kann, um von diesem die eigentliche Invoice anzufordern. Dieser QR-Code enthält neben der URL, über die die Rechnung angefordert werden kann, auch einen Mindest- und Höchstbetrag für die Zahlung. Der Zahlungswillige kann nach dem Scannen des Codes schließlich den Endbetrag selbst festlegen und die Zahlung an die vom Webserver generierte Rechnung tätigen. Auch wenn dies auf den ersten Blick gegebenenfalls kompliziert klingt, ist es in der Praxis doch recht einfach:

LN-Wallet öffnen → QR-Code scannen → gewünschten Betrag eintippen → Senden → fertig.

LNURL-withdraw

Einen ähnlichen, wenngleich umgekehrten Anwendungsfall bedient das Sub-Protokoll LNURL-withdraw. Hierbei wird einem Webserver eine Invoice zur Verfügung gestellt, der diese dann automatisch bezahlt, sofern sie gültig ist und einigen festgelegten Parametern entspricht. In der Fiat-Welt ist dieses wohl am ehesten mit dem Verfahren des Bankeinzugs zu vergleichen. Als Paradebeispiel für die Anwendung von LNURL-withdraw wird oft die Abhebung von Börsenkonten oder ähnlichen genannt. Beispielsweise beim Cashback-Service von Satsback.com kommt LNURL-withdraw zum Einsatz. Als Nutzer sammelt man über einen gewissen Zeitraum Geld in Form von Satoshis auf der Plattform an und möchte diese schlussendlich auf seine eigene Wallet auszahlen. Mithilfe von LNURL-withdraw kann der Nutzer nun auf der Webseite von Satsback einfach einen QR-Code generieren lassen, diesen scannen und den gewünschten Betrag abheben. Auch für Trinkgelder in Form von kleinen ausgedruckten QR-Codes eignet sich diese Lösung.

Lightning Adressen

Sogenannte Lightning-Adressen sind im Grunde nur ein spezieller Anwendungsfall, oder wenn man so möchte, eine Weiterentwicklung von LNURL-pay. Diese "E-Mail-Adressen für Bitcoin", können verwendet werden, um Zahlungen zu versenden, ohne QR-Codes scannen oder Rechnungs-Informationen kopieren zu müssen.

Lightning-Adresse in LN-Wallet eintippen → Betrag eingeben → Senden → fertig

Viele Lightning-Wallets und Services stellen ihren Nutzern heute bereits eine individuelle Lightning-Adresse zur Verfügung, über die diese Zahlungen empfangen können. Dies ist definitiv eine große Bereicherung für die Nutzerfreundlichkeit des LN.

Was ist BOLT12?

Lasst uns nun zu BOLTs allgemein und im Speziellen zu BOLT12 kommen. Das Kürzel BOLT ist ein Akronym für "Basis Of Lightning Technology", was zu Deutsch etwa "Grundlage der Lightning Technologie" bedeutet. Diese sogenannten BOLTs sind eine Art von Spezifikationsentwürfen, die mit den bekannteren BIPs (Bitcoin Improvement Proposals) vergleichbar sind. Im Zusammenhang mit den weiter oben genannten UX-Problemen liegt derzeit ein besonderes Augenmerk auf der Entwicklung des BOLT12-Standards, der neben LNURL einige deutliche Verbesserungen in diesem Bereich verspricht, aber nicht auf einen Webserver angewiesen ist. Um zu verstehen, welche Probleme BOLT12 genau lösen soll, ist es notwendig zunächst einen Blick auf den aktuellen LN-Standard zu werfen, mit dem Rechnungen im Lightning-Netzwerk generiert werden - BOLT11.

Probleme bei BOLT11

Invoices, die mittels BOLT11 erstellt werden, beinhalten im Wesentlichen drei wichtige Komponenten.

1. Ein Ziel, an welches die Zahlung geschickt werden soll (Pubkey der Node)
2. Der zu sendende Betrag (in Sats)
3. Einen Hash der als Zahlungsgeheimnis fungiert

Um sich die genaue Zusammensetzung einer BOLT11-Invoice genauer klarzumachen, empfiehlt sich ein Besuch auf der Seite https://www.bolt11.org/. Dort werden alle Bestandteile (im unten stehenden Bild jeweils farbig gekennzeichnet) detailliert beschrieben.

Das größte Problem von BOLT11-Invoices ist, dass diese jeweils nur einmal benutzt werden können und darum jeweils in Echtzeit generiert werden müssen. Nach der Erstellung der Rechnung kann das Zahlungsgeheimnis preisgegeben und somit unsicher werden. Würde man eine neue Rechnung mit demselben Geheimnis erstellen, könnte jemand, dadurch, dass er das Geheimnis bereits kennt, Gelder einfordern, die ihm überhaupt nicht zustehen. Genau aus diesem Grund sind, wie weiter oben bereits genannt, BOLT11-Invoices nicht dazu geeignet, QR-Codes auf Spendenseiten bereitzustellen oder andere Szenarien abzubilden, die einen großen Zeitversatz zwischen dem Erstellen einer Rechnung und deren Bezahlung vorweisen.

BOLT12 fixes this!

Mit BOLT12 wird ein neues Schema respektive ein neuer Typ für Invoices eingeführt, die sogenannten "Offers" (dt. Angebote). Wie die Entwickler von LN.Capital in einem Tweet darlegten, kann man sich eine solche "Offer" als eine Art "Meta-Invoice über der eigentlichen Invoice" vorstellen. Das Tolle an den Offers ist, dass diese statisch und wiederverwendbar sind und immer auf dieselbe Node verweisen. Dadurch kann einfach bei Bedarf auf Grundlage der Offer eine neue Invoice generiert werden. Um allerdings eine Rechnung von der Node, die die Offer erstellt hat, zu erhalten, müssen die für die Rechnungserstellung notwendigen Informationen zu dieser gelangen. Dazu zählt unter anderem die Node-ID, die Währung, in der bezahlt wird, ein Mindestbetrag, eine Verfallszeit oder im Falle von Shops auch Mindest- oder Höchstmengen bei der Bestellung und Bezahlung mehrerer Artikel.

Über sogenannte "Onion-Messages" kann eine direkte und Ende-zu-Ende-verschlüsselte Verbindung zwischen zwei Nodes hergestellt werden, ohne dass ein Lightning-Kanal erforderlich ist (siehe auch BOLT7). Über diese Oninon-Messages, kann somit eine Anfrage für eine Invoice gesendet werden, die dann mit einer solchen beantwortet wird.

Interessanterweise funktionieren BOLT12 Offers in beide Richtungen. Das bedeutet, dass damit sowohl der Usecase von LNURL-pay als auch LNURL-withdraw abgedeckt werden kann. Das bedeutet, dass eine BOLT12-Offer nicht nur Geld empfangen, sondern auch senden kann. Dies bietet einige neue Anwendungsfälle, wie zum Beispiel den Einsatz in BTC-Geldautomaten. Ein Geldautomat, der Euro annehmen und Bitcoin via Lightning auszahlen soll, kann mit BOLT11 nicht (nutzerfreundlich) funktionieren, weil man zuerst eine Invoice über den gewünschten Betrag erstellen und diese an den Automaten übertragen müsste. Mit einer BOLT12-Offer hingegen, kann man einfach seine Geldscheine in den Automaten einführen und sich die Sats direkt auf das eigene LN-Wallet auszahlen lassen. Rückerstattungen in Shops sind bisher aufgrund der Invoice-Problematik nicht möglich. Mit BOLT12 jedoch kein Problem mehr, da ein User einfach eine "Rückerstattungs-Offer" scannen kann um sich sein Geld zurückzuholen. Auch Abo-Funktionen wären denkbar, bei denen die BOLT12-Offer die entsprechenden Nutzer täglich, wöchentlich, monatlich, oder jährlich zu einer Zahlung veranlasst.

LNURL vs. BOLT12 - was ist besser?

Sowohl durch LNURL als auch BOLT12 wird das "Bezahlen" und "Bezahlt werden" im Lightning-Netzwerk um ein Vielfaches einfacher und nutzerfreundlicher. Während LNURL jedoch auf der Anwendungsebene verankert ist, bietet BOLT12 eine Lösung direkt auf Protokollebene. Die Offers respektive Meta-Invoices benötigen keinen Webserver, TLS-Zertifikate oder Domain und bieten daher auch einen besseren Datenschutz als LNURL. Durch die Nutzung sogenannter "Blinded Paths", müssen BOLT12-Offers auch die Node-ID nichtmehr öffentlich machen. Ein weiterer Pluspunkt hinsichtlich des Datenschutzes und der Privatsphäre. Gleichwohl können beide Lösungen gut nebeneinander bestehen. Da Online-Shops und andere Dienstleister oft ohnehin einen eigenen Webserver betreiben, ist LNURL eine gut funktionierende und vor allem bereits getestete Lösung. BOLT12 soll hingegen vor allem für Endnutzer weitere Erleichterungen bringen.

BOLT12 befindet sich derzeit zwar noch in der Entwicklung, wird aber bereits von der vom Unternehmen Blockstream entwickelten Implementation Core Lightning/c-Lightning experimentell unterstützt.

---