Blockchain/Niveau V · Layer/5.1 Lightning/Lektion 3
Rechnungen: BOLT11 und BOLT12
Von Einweg-Strings zu wiederverwendbaren Offers – und die Webserver, die die Lücke überbrückten
MaterialienEine Lightning-Wallet, die Rechnungen dekodieren kannEin öffentliches BOLT11-Decoder-Tool, das über den Browser zugänglich istEine BOLT11-Beispielrechnung und ein BOLT12-Offer-String
Neugier
- Warum zwingt eine Zahlungsanforderung, die nach einer Stunde abläuft, Händler dazu, ständig neue zu erzeugen?
- Wie kann ein statischer QR-Code jahrelang gültig bleiben und dennoch für jede Transaktion einzigartige, sichere Rechnungen erzeugen?
- Welche konkreten Datenfelder ermöglichen es einer Wallet, vor dem Senden von Geldern zu überprüfen, dass eine Rechnung nicht manipuliert wurde?
Erkunden
- Eine BOLT11-Rechnung ist ein bech32-String, der mit „lnbc“ beginnt und alle notwendigen Zahlungsparameter enthält. Er kodiert einen optionalen Betrag (in Bitcoin, mit einem Multiplikator-Buchstaben, bis hinunter zu Bruchteilen eines Satoshis), einen spezifischen Payment-Hash, der aus einem geheimen Preimage abgeleitet ist, und einen Ablaufzeitstempel, der standardmäßig eine Stunde beträgt. Der öffentliche Schlüssel des Empfänger-Nodes identifiziert das Ziel, während optionale Routing-Hinweise dem Zahler helfen, wenn keine direkten Kanäle verfügbar sind. Der gesamte String wird vom Empfänger signiert, was seine Integrität sicherstellt.
- Dieser Aufbau macht BOLT11-Rechnungen strikt einmalig verwendbar. Sobald ein Sender den zugehörigen Payment-Hash bezahlt hat, ist die Rechnung beglichen und kann nicht erneut eingelöst werden. Eine zweite Zahlung ist unsicher: Nach der ersten Zahlung kennt jeder Node auf dieser Route das Preimage, sodass jeder dieser Nodes, der auch auf der Route der zweiten Zahlung liegt, diese an sich nehmen könnte. Diese Einschränkung erfordert im Einzelhandel dynamische QR-Codes: Händler müssen für jeden Kunden einen neuen String erzeugen, was die Kassenhardware verkompliziert.
- Entwickler aus der Community begegneten dieser Hürde mit LNURL und Lightning-Adressen, die auf externe Webserver angewiesen sind. Ein Nutzer scannt eine statische URI, die auf einen Server-Endpunkt verweist; die Wallet ruft vor dem Start der Zahlung eine neue BOLT11-Rechnung von diesem Server ab. Dadurch wird die öffentliche Adresse von den konkreten Transaktionsdaten entkoppelt: Ein einziger Link kann unbegrenzt viele Zahlungen bedienen, während im Hintergrund weiterhin die Sicherheit eindeutiger, einmal verwendbarer Rechnungen erhalten bleibt.
- BOLT12-„Offers“, entworfen von Rusty Russell und 2024 in die Spezifikation aufgenommen, verlagern diesen Ablauf in das Protokoll selbst. Diese wiederverwendbaren Zahlungscodes beginnen mit „lno“ und dienen als statische Kennungen für einen Empfänger-Node. Beim Scannen sendet die Wallet des Zahlers eine Onion-Message direkt über das Lightning Network, um beim Ersteller des Offers eine neue Rechnung abzurufen. Dadurch entfällt die Abhängigkeit von externen Webservern, und die Erzeugung von Zahlungsanforderungen wird in das Kernprotokoll integriert.
- BOLT12-Offers unterstützen Funktionen, die es in BOLT11 nicht gibt, darunter Abläufe, bei denen der Händler den Nutzer bezahlt, etwa Rückerstattungen oder Auszahlungen (wiederkehrende Zahlungen waren im Entwurf vorgesehen, wurden aber aus der zusammengeführten Spezifikation entfernt). Offers können außerdem Blinded Paths nutzen, um den empfangenden Node im Kanalgraphen zu verbergen, statt seinen öffentlichen Schlüssel zu veröffentlichen. Dieses Design gibt weniger private Informationen preis als Standardrechnungen, die Routing-Hinweise oder Fallback-Adressen direkt offenlegen.
- Spontane Zahlungen umgehen Rechnungen vollständig mithilfe der Protokolle Keysend oder AMP (Atomic Multi-Path), bei denen Sender Gelder ohne vorherige Anfrage an einen bekannten Node-Schlüssel übertragen. Zur praktischen Überprüfung fügen Sie eine beliebige Lightning-Rechnung in einen öffentlichen BOLT11-Decoder ein. Identifizieren Sie das menschenlesbare Präfix, den Betrag, den Payment-Hash, die Ablaufzeit und die Signatur des Empfängers. Vergleichen Sie dies mit einem „lno“-String, der keinen Payment-Hash enthält, sondern nur das, was der Zahler benötigt, um eine Rechnung anzufordern: die Node-ID oder Blinded Paths zu diesem Node.
Kernfakten
- BOLT11-Rechnungen sind einmal verwendbare bech32-Strings, die mit „lnbc“ beginnen und Betrag, Hash und Signatur kodieren.
- LNURL und Lightning-Adressen nutzen Webserver, um über statische Links neue BOLT11-Rechnungen abzurufen.
- BOLT12-Offers beginnen mit „lno“ und erzeugen über Onion-Messages im Lightning Network eindeutige Rechnungen.
- BOLT12-Offers sind wiederverwendbar und unterstützen Zahlungen vom Händler an den Nutzer, etwa Rückerstattungen – was BOLT11 nicht kann.
- Die Standard-Gültigkeitsdauer für eine BOLT11-Rechnung beträgt eine Stunde (3600 Sekunden).
- Keysend ermöglicht spontane Zahlungen an den öffentlichen Schlüssel eines Nodes ohne Rechnung.
Übung neun, sechs, drei, eins
9SammelnListen Sie 9 verschiedene Formate oder Kennungen für Zahlungsanforderungen auf, die im digitalen Finanzwesen verwendet werden – von herkömmlichen Banküberweisungscodes bis zu modernen Kryptostandards. Geben Sie jeweils an, ob das Format einmalig oder wiederverwendbar ist.
6GruppierenGruppieren Sie die 9 danach, wie sie mit Eindeutigkeit umgehen, in 6 Kategorien: statisch-wiederverwendbar, dynamisch-einmalig, serververmittelter Neuabruf, protokollnativer Neuabruf, schlüsselbasiert-spontan oder Sonstiges.
3VerdichtenReduzieren Sie die 6 Gruppen auf 3 grundlegende Kompromisse zwischen Benutzerkomfort (statische Codes) und kryptografischer Sicherheit (eindeutige Hashes).
1KristallisierenSchreiben Sie 1 Satz, der erklärt, warum BOLT12-Offers externe Webserver in wiederverwendbaren Zahlungsabläufen überflüssig machen.
Faktcheck
Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.