BOLT 12 ist ein Lightning-Protokoll zur Zahlungsaushandlung über offer, invoice_request und invoice. Das Angebot ist wiederverwendbar, jede Zahlung hat jedoch eigene Bedingungen und ein zu prüfendes Ergebnis.
Der Empfänger veröffentlicht ein offer; der Zahler sendet invoice_request und erhält eine neue invoice. Erst danach kann er zahlen. Ein Angebot kann mehreren Personen oder wiederholten Zahlungen dienen. Eine Rechnung etwa mit fetchinvoice abzurufen bezahlt sie nicht; ein veröffentlichter QR ist keine dauerhafte Abbuchungserlaubnis. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice] [BOLT 12 — Project overview]
BOLT 12 speichert Felder als TLV. Textangebote verwenden lno, Anforderungen lnr; das Alphabet ähnelt Bech32, besitzt aber keine abschließende Prüfsumme. Das offer selbst ist nicht signiert. BIP340-Schnorr-Signaturen in Anforderungen und Rechnungen prüfen die Merkle-Wurzel der Felder, nicht die Identität des Händlers. [BOLT 12 — Negotiation protocol]
Die Wallet vergleicht übernommene invoice_request-Felder mit invoice, Betrag, Blockchain und Signatur. invoice_node_id muss zu offer_issuer_id oder dem jeweiligen letzten blinded_node_id passen. Eine gültige fremde Signatur genügt nicht. Die Merkle-Struktur erlaubt selektive Feldnachweise, keine beliebige Änderung signierter Bedingungen. [BOLT 12 — Negotiation protocol]
Bitcoin invoice_amount wird in msat angegeben; 1000 msat sind ein Satoshi. offer_currency kann eine andere Währung nach ISO 4217 nennen; USD nutzt beispielsweise Cent. Menge und Umrechnung bei Rechnungserstellung beeinflussen den Preis. Ist invreq_amount angegeben, muss die Rechnung übereinstimmen; sonst gilt die Prüfung des autorisierten Bereichs. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
offer_paths führt die Anforderungsnachricht, invoice_paths die Zahlung. Eine aktuelle invoice muss blinded paths und passendes invoice_blindedpay enthalten, selbst bei direktem Weg zum Empfänger. Verblindung begrenzt Topologieoffenlegung, garantiert aber weder vollständige Anonymität noch Verfügbarkeit oder Liquidität. Die Rechnungsanforderung benötigt keinen gewöhnlichen HTTPS-Zahlungsserver. [BOLT 12 — Negotiation protocol] [BOLT 4 — Route blinding]
offer_absolute_expiry begrenzt das Angebot. invoice_created_at und invoice_relative_expiry begrenzen die konkrete Rechnung; ohne das zweite Feld gelten 7200 Sekunden. Wiederverwendbarkeit macht Rechnungen nicht unbegrenzt gültig. Unbekannte gerade Pflichtfunktionsbits werden abgelehnt, unbekannte ungerade ignoriert. [BOLT 12 — Negotiation protocol]
Bei einer Erstattung kann der Geldsender invoice_request ohne offer veröffentlichen. Der Geldempfänger antwortet mit eigener invoice; der Zahler muss den beabsichtigten Empfänger nötigenfalls außerhalb des Protokolls prüfen. Das ist eine neue Zahlung, keine Aufhebung der ursprünglichen. Das Scannen allein belegt weder Anspruch noch Zahlungsfreigabe. [BOLT 12 — Negotiation protocol]
Invoice, Zahlungsstatus und passendes Preimage aufbewahren. Das Preimage belegt die Rechnungsabwicklung, identifiziert aber allein keinen menschlichen Zahler. Nach verlorener Antwort vor weiterer Zahlung den Status prüfen. Angebotsunterstützung bedeutet nicht Unterstützung jeder Erweiterung oder automatischer Wiederholungszahlungen; Empfang, Versand und App-Berechtigungen getrennt prüfen. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
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, Rusty Russell.