BOLT 11 ist der Standard für eine signierte Lightning-Rechnung in Bech32. Sie enthält Payment Hash, Empfängerinformationen und Zahlungsbedingungen; sie ist eine Anforderung, kein Beleg erfolgreicher Zahlung.
Bech32 erkennt Übertragungsfehler durch eine Prüfsumme; es verschlüsselt nicht. Eine ECDSA-Signatur über secp256k1 schützt den Rechnungsinhalt und bindet ihn an den Empfängerschlüssel, nicht an eine verifizierte Person. Anders als Bech32-Adressen hat BOLT 11 keine Grenze von 90 Zeichen. QR-Codes dürfen Großbuchstaben verwenden; gemischte Schreibweise ist ungültig. [BOLT 11 — Invoice protocol]
lnbc bezeichnet Mainnet, lntb Testnet, lntbs Signet und lnbcrt Regtest. Der Betrag steht in BTC mit Multiplikator m, u, n oder p. Bei p muss die letzte Ziffer 0 sein, damit ganze msat entstehen; 1000 msat sind ein Satoshi. Fehlt der Betrag, ergänzt ihn der Zahler; das bedeutet keine Nullzahlung. [BOLT 11 — Invoice protocol]
Feld p enthält den Payment Hash: SHA256 des Payment Preimage. Feld s enthält payment_secret, das der Empfänger im letzten Teil der gerouteten Zahlung verlangt. Das Secret ist weder Preimage noch Wallet-Seed. Aktuelles BOLT 11 verlangt beide Felder; das Auslesen des Secret beweist keine Zahlung. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
Eine Rechnung enthält genau eine Variante: Text d oder Hash h einer externen Beschreibung. Bei h muss die Wallet deren SHA256 prüfen; der Hash allein erklärt keinen Kauf. Die Signatur bindet Inhalt an einen Schlüssel, bestätigt aber kein Händlerversprechen. Dekodierter Text ist sicher als Daten anzuzeigen. [BOLT 11 — Invoice protocol]
Timestamp plus x bestimmt den Ablauf; ohne x gelten standardmäßig 3600 Sekunden. Feld c ist min_final_cltv_expiry_delta für den letzten HTLC in Blöcken, keine weitere Lebensdauer in Sekunden; fehlt es, gelten mindestens 18 Blöcke. Der Rechnungsablauf macht eine abgeschlossene Zahlung nicht rückgängig. [BOLT 11 — Invoice protocol]
Feld 9 kennzeichnet erforderliche und optionale Funktionen. Ein unbekanntes gerades Bit verlangt Ablehnung, ein unbekanntes ungerades wird ignoriert; bekannte Funktionsabhängigkeiten müssen erfüllt sein. Basic MPP ist nur bei angebotenem basic_mpp zulässig. Teilzahlungen erzeugen keine mehreren unabhängigen Rechnungen. [BOLT 11 — Invoice protocol] [BOLT 9 — Assigned feature flags]
Feld r ergänzt Routing Hints zum Empfänger und kann Knotenschlüssel, Kanalnummern und Gebührenparameter offenlegen. Es belegt keine aktuelle Liquidität. Optionales f kann eine On-chain-Adresse anbieten: eine andere Zahlungsart mit eigenen Gebühren und Bestätigungen. Die Rechnung ist daher weder ein privater noch dauerhaft wiederverwendbarer Kontakt. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
Nach dem Senden sind ausstehende und abgeschlossene Ergebnisse zu unterscheiden. Rechnung und passendes Preimage als Abwicklungsbelege aufbewahren, nicht nur ein QR-Bild. Bei verlorener Antwort zuerst den Wallet-Status prüfen. Eine neue Rechnung oder andere Zahlungsart kann eine weitere Zahlung auslösen; das Format allein bietet keinen universellen Wiederholungsschutz. [BOLT 4 — Onion routing] [Core Lightning — Payment result]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Lightning Network, HTLC, BOLT 12, Nostr Wallet Connect, Satoshi. Auf diesen Eintrag verweisen außerdem Nostr Wallet Connect, BOLT 12, LNURL, Lightning Address.