BOLT 12 ist ein Protokoll zur Vereinbarung einer Zahlung im Lightning Network. Es unterscheidet das Angebot offer, die Anfrage invoice_request und die daraus entstehende Rechnung invoice. Das Angebot kann für mehrere Zahlungen veröffentlicht bleiben, während jede Rechnung die Bedingungen der konkreten Zahlung festlegt.
Stellen Sie sich ein Café vor, das einen einzigen Code für freiwillige Beiträge auf dem Tresen haben möchte. Dieselbe gewöhnliche BOLT-11-Rechnung wiederholt zu bezahlen wäre problematisch. BOLT 12 veröffentlicht stattdessen eine offer. Die Wallet des Gastes sendet daraufhin eine invoice_request, fordert also eine eigene Rechnung an, und der Empfänger antwortet mit einer neuen invoice. Erst diese wird bezahlt. Ein gedruckter QR kann so mehreren Menschen dienen, ohne dass alle dieselbe Rechnung verwenden. Eine Rechnung abzurufen, etwa mit fetchinvoice, versendet noch kein Geld. Das Angebot erteilt dem Café auch keine Erlaubnis, weitere Beträge aus fremden Wallets einzuziehen. [1] [3] [4]
Ein Angebot kann den Preis in Bitcoin oder in einer anderen Währung nennen. Das Feld offer_currency verwendet Codes nach ISO 4217; ein Betrag in USD wird etwa in Cent angegeben. Bei der Rechnungserstellung können Stückzahl und Währungsumrechnung berücksichtigt werden. Die endgültige Bitcoin-Rechnung nennt invoice_amount jedoch in Millisatoshi, also Tausendstel eines Satoshi: 1000 msat = 1 sat. Vor dem Bezahlen muss der Zahlende diesen Betrag und die Gebühr kennen, nicht nur das ursprüngliche Preisschild. Gibt die Anfrage eine genaue invreq_amount vor, muss die Rechnung damit übereinstimmen. Andernfalls prüft die Wallet den genehmigten Bereich und sollte außerhalb dieses Bereichs erneut um Zustimmung bitten. Eine Umrechnung ist keine stillschweigende Zustimmung zu jedem Preis. [1] [3]
Der gedruckte Code kann auf dem Tresen bleiben, doch auch das Angebot kann mit offer_absolute_expiry ablaufen. Jede Rechnung hat zusätzlich einen Erstellungszeitpunkt invoice_created_at und eine Gültigkeitsdauer invoice_relative_expiry. Fehlt diese Dauer, gelten standardmäßig 7200 Sekunden, also zwei Stunden. Eine alte Rechnung ist deshalb kein dauerhaft gültiger Kontakt. Wallets müssen außerdem die in Nachrichten verlangten Funktionen verstehen. Ein unbekanntes gerades Bit bezeichnet eine Pflichtfunktion und führt zur Ablehnung; ein unbekanntes ungerades Bit ist optional und kann ignoriert werden. Das dient sicherer Kompatibilität und ist kein Hindernis, das Nutzer durch Umschreiben des Codes umgehen sollten. [1]
Bewahren Sie nach dem Bezahlen die Rechnung und das Ergebnis der Wallet auf. Zu den Belegen gehört auch das preimage, ein geheimer Wert, den die Wallet beim Abschluss der Zahlung erhält. Sie berechnet daraus einen Hash, also einen Prüfwert, und vergleicht ihn mit dem Zahlungs-Hash der Rechnung. Zusammen mit der Rechnung lässt sich damit deren Bezahlung belegen, aber allein noch nicht feststellen, welcher Mensch bezahlt hat. Bricht die Verbindung ab oder geht die Antwort verloren, prüfen Sie vor einem neuen Versuch den Status der vorigen Zahlung. Eine neue Rechnung kann zu einer weiteren Zahlung führen. Prüfen Sie Versprechen zu wiederkehrenden Zahlungen ebenso sorgfältig. BOLT-12-Unterstützung bedeutet nicht automatisch jede Erweiterung oder die Erlaubnis zum automatischen Einzug. Klären Sie getrennt, ob die Wallet Zahlungen über Angebote empfangen, fremde Angebote bezahlen kann und welche Rechte eine verbundene App hat. [1] [3]
Rechnungsanforderung und Geldtransfer nutzen das Netz für unterschiedliche Zwecke. offer_paths führt die Anfrage weiter, invoice_paths liefert dagegen Zahlungsrouten. BOLT 12 verwendet blinded paths: Wege, die einen Teil der Verbindungsinformationen zum Empfänger verbergen. Weniger offengelegte Netzstruktur hilft der Privatsphäre, verspricht aber keine vollständige Anonymität. Ein verborgener Weg garantiert weder einen erreichbaren Empfänger noch Liquidität, also genügend Geld auf den nötigen Seiten der Zahlungskanäle. Technisch muss eine aktuelle invoice diese Wege samt zugehörigen Zahlungsparametern invoice_blindedpay enthalten, selbst bei einem direkten Weg zum Empfänger. Für die Rechnungsanfrage ist kein herkömmlicher HTTPS-Zahlungsserver nötig. [1] [2]
Will ein Händler Geld zurückzahlen, kehrt sich die Richtung der Abstimmung um. Der künftige Zahlende kann eine invoice_request ohne vorherige offer veröffentlichen. Der Kunde als Empfänger antwortet mit einer eigenen invoice, die der Händler bezahlt. Das löscht oder widerruft die ursprüngliche Zahlung nicht, sondern erzeugt eine neue in Gegenrichtung. Der Händler muss prüfen, ob die Rechnung zum beabsichtigten Empfänger gehört, gegebenenfalls durch eine Absprache außerhalb des Protokolls. Das Scannen einer Anfrage beweist weder einen Erstattungsanspruch noch genehmigt es den Geldtransfer. Der technische Ablauf erleichtert die Kommunikation; er entscheidet nicht, wem Geld zusteht. [1]
BOLT 12 speichert Daten als TLV: Jedes Feld nennt Typ, Länge und Wert. Ein Textangebot beginnt mit lno, eine Anfrage mit lnr. Der Zeichensatz ähnelt Bech32, besitzt aber nicht dessen abschließende Prüfsumme. Allein daraus folgt noch nicht, wer Geld erhalten darf. Die offer selbst ist unsigniert. BIP340-Schnorr-Signaturen sichern die Rechnung und die gewöhnliche Anfrage als Antwort auf ein Angebot ab. Eine eigenständige Anfrage ohne vorheriges Angebot, etwa für eine Rückzahlung, enthält keine Signatur. Die Signatur bindet die Wurzel einer Merkle-Struktur ein: einen gemeinsamen Prüfwert, der aus den betreffenden Feldern berechnet wird. So lassen sich ausgewählte Felder nachweisen, ohne stets jedes Detail offenzulegen. Das erlaubt weder Änderungen signierter Bedingungen noch beweist es die bürgerliche Identität des Händlers. [1]
Die Wallet muss feststellen, dass sie eine Antwort auf ihre Anfrage erhalten hat und nicht bloß irgendeine korrekt signierte Rechnung. Dazu vergleicht sie die übernommenen invoice_request-Felder mit der invoice sowie Netzwerk, Betrag und Signatur. Der öffentliche Schlüssel invoice_node_id muss offer_issuer_id entsprechen; verwendet das Angebot stattdessen den betreffenden verborgenen Weg ohne diese Kennung, prüft die Wallet dessen letzten blinded_node_id. Es ist wie die Prüfung, ob eine Rechnung zu Ihrem Tisch gehört, statt nur, ob ihr Stempel echt ist. Die Merkle-Struktur erlaubt Nachweise ausgewählter Angaben, entbindet die Wallet aber nicht davon, alle zahlungsrelevanten Bedingungen zu prüfen. Eine fremde gültige Rechnung wird durch eine korrekte Signatur nicht zur richtigen. [1]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit BOLT 11, Lightning Network, Lightning Routing, Bitcoin-Privatsphäre, Satoshi, LNURL. Auf diesen Eintrag verweisen außerdem BOLT 11, LNURL, Just-in-Time Channels.