BOLT 11

Anna kauft ein E-Book. Statt einer Bankverbindung zeigt der Shop eine Lightning-Rechnung, aus der ihre Wallet die Zahlungsdaten liest. Anna muss die lange Zeichenfolge nicht verstehen: Vor der Bestätigung prüft sie Betrag, Zweck und Gebühr. Manche Rechnungen lassen den Betrag offen, etwa für freiwillige Beiträge. Dann trägt ihn der Zahlende ein; ein fehlender Betrag bedeutet keine Zahlung von null. Für Neugierige: lnbc kennzeichnet das Hauptnetz, lntb das Testnet, lntbs Signet und lnbcrt Regtest, also Testumgebungen. Der codierte Betrag steht in BTC, gegebenenfalls mit dem Multiplikator m, u, n oder p, nicht direkt in Satoshi. Bei p muss er auf 0 enden, damit er ganze Millisatoshi ergibt: 1000 msat = 1 sat. [1]

Die Beschreibung verbindet die technischen Zahlungsdaten mit einem verständlichen Zweck, etwa Annas Buch. Die Rechnung enthält entweder den Text selbst im Feld d oder dessen digitalen Fingerabdruck im Feld h. Dieser wird mit SHA256 berechnet. Ein solcher kurzer, aus dem Text berechneter Prüfwert heißt Hash. Die Wallet muss prüfen, dass eine separat übermittelte Beschreibung denselben Fingerabdruck ergibt. Aus dem Fingerabdruck allein lässt sich die Bestellung nicht ablesen. Eine gültige Signatur bindet die Beschreibung an den Schlüssel des Empfängers, verspricht aber nicht, dass der Händler das Buch liefert. Für Entwickler gilt außerdem: Die Beschreibung ist fremder Text, der sicher als Daten angezeigt und niemals als Code ausgeführt werden darf. [1]

Anna lässt die Bestellung offen und kehrt später zurück. Meldet die Wallet eine abgelaufene Rechnung, sollte sie eine neue anfordern. Das Ende der Gültigkeit ergibt sich aus dem Erstellungszeitpunkt timestamp und der Dauer x. Fehlt x, gelten standardmäßig 3600 Sekunden, also eine Stunde. Der Ablauf macht eine abgeschlossene Zahlung nicht rückgängig. Feld c, technisch min_final_cltv_expiry_delta, regelt etwas anderes: den Zeitpuffer für die letzte bedingte Zahlung, ein HTLC, auf der Route. Ein HTLC setzt voraus, dass rechtzeitig das passende Geheimnis vorgelegt wird. Dieser Puffer wird in Blöcken gemessen, nicht in Gültigkeitssekunden; ohne c verwendet der Zahlende mindestens 18 Blöcke. Die beiden Zeitangaben dürfen nicht verwechselt werden. [1]

Lightning-Zahlungen laufen durch Zahlungskanäle. Darin aktualisieren zwei Parteien laufend die Aufteilung ihrer Mittel, ohne jede gewöhnliche Zahlung in der Bitcoin-Blockchain zu verzeichnen. Für eine erfolgreiche Zahlung braucht es eine nutzbare Route und genügend Geld auf den jeweils richtigen Kanalseiten, also Liquidität. Feld r kann routing hints enthalten: Hinweise für den letzten Teil des Weges. Sie helfen, den Empfänger zu erreichen, zeigen aber nicht die aktuell verfügbare Kapazität. Außerdem können sie öffentliche Knotenschlüssel, Kanalkennungen und Gebührenparameter offenlegen. Behandeln Sie die vollständige Rechnung deshalb nicht als privat. Das optionale Feld f kann eine gewöhnliche Bitcoin-Adresse als Ausweichmöglichkeit anbieten. Dorthin zu zahlen bedeutet eine Zahlung auf der Hauptkette mit eigenen Gebühren und Bestätigungen, nicht bloß einen anderen Knopf für denselben Zustellweg. [1] [2] [5]

Ein gescannter QR-Code und eine empfangene Rechnung sind keine Quittung. Prüfen Sie nach dem Senden das Ergebnis in der Wallet: Ausstehend ist etwas anderes als abgeschlossen. Zur erfolgreichen Abwicklung gehört auch das richtige preimage, ein geheimer Wert, dessen Hash mit dem Zahlungs-Hash der Rechnung übereinstimmen muss. Rechnung und Wert können als Zahlungsnachweis aufbewahrt werden, garantieren jedoch keine Warenlieferung. Bricht die Verbindung ab oder geht die Antwort verloren, prüfen Sie zuerst den Status der ursprünglichen Zahlung. Eine sofort angeforderte neue Rechnung oder die Ausweichadresse kann zu einer weiteren Zahlung führen. Manche Wallets erkennen Wiederholungen, doch das Format bietet keinen universellen Schutz über verschiedene Anwendungen und Zahlungswege hinweg. [2] [4]

Die lange Zeichenfolge ist in Bech32 codiert. Dessen Prüfsumme erkennt Übertragungsfehler; sie ist keine Verschlüsselung und verbirgt den Inhalt nicht. Eine andere Aufgabe hat die digitale ECDSA-Signatur auf secp256k1: Sie prüft die Bindung der Zahlungsdaten an den Empfängerschlüssel und schützt vor nachträglichen Änderungen. Sie bestätigt weder die bürgerliche Identität noch die Ehrlichkeit der Person dahinter. Anders als Bitcoin-Adressen in Bech32 darf BOLT 11 länger als 90 Zeichen sein. Für QR-Codes eignen sich Großbuchstaben; eine gültige Zeichenfolge darf Groß- und Kleinschreibung aber nicht mischen. Menschen scannen oder kopieren meist, während ihre Wallet diese Prüfungen übernimmt. [1]

Der payment hash ist der mit SHA256 berechnete digitale Fingerabdruck eines geheimen payment preimage und steht im Feld p. Bei erfolgreicher Abwicklung erfährt der Zahlende das preimage und kann den Fingerabdruck vergleichen. Feld s enthält dagegen payment_secret. Diesen Wert liest der Zahlende bereits aus der Rechnung und übermittelt ihn im letzten Abschnitt der gerouteten Zahlung an den Empfänger. Er hilft, diesen vor Sondierungsversuchen weiterleitender Knoten zu schützen. Secret ist weder preimage noch Wallet-Seed. Ihn aus einem QR-Code zu lesen beweist daher keine Zahlung und erlaubt keine Wiederherstellung der Wallet. Der aktuelle BOLT-11-Standard verlangt sowohl p als auch s: ähnliche Namen, aber unterschiedliche Aufgaben bei Zuordnung, Übermittlung und Zahlungsnachweis. [1] [2]

Wallets müssen auch erkennen, ob sie die geforderte Zahlung unterstützen. Feld 9 enthält Funktionsmerkmale. Ein unbekanntes gerades Bit steht für eine verpflichtende Funktion und verlangt die Ablehnung der Zahlung; ein unbekanntes ungerades Bit ist optional und darf ignoriert werden. Bekannte Abhängigkeiten zwischen Funktionen müssen ebenfalls erfüllt sein. Basic MPP etwa teilt eine Zahlung in mehrere Teile auf, die beim Empfänger zusammengeführt werden. Das ist nur erlaubt, wenn die Rechnung basic_mpp anbietet. Daraus werden weder mehrere eigenständige Rechnungen noch Gründe, jeden Teil erneut zu bezahlen. Für Einsteiger heißt das: Eine Meldung über eine nicht unterstützte Funktion nicht durch manuelles Ändern der Rechnung umgehen, sondern die Kompatibilität der Wallets klären. [1] [3]