BOLT 12 négocie un paiement Lightning avec offer, invoice_request et invoice. L’offre est réutilisable, mais chaque paiement a ses propres conditions et un résultat à vérifier.
Le destinataire publie offer ; le payeur envoie invoice_request et reçoit une nouvelle invoice. Il peut ensuite payer. L’offre peut servir à plusieurs personnes ou paiements répétés. Obtenir une facture, par exemple avec fetchinvoice, ne la paie pas ; un QR publié n’autorise pas des prélèvements permanents. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice] [BOLT 12 — Project overview]
BOLT 12 stocke les champs en TLV. Les offres textuelles utilisent lno et les demandes lnr ; l’alphabet ressemble à Bech32, sans somme de contrôle finale. L’offer elle-même n’est pas signée. Les signatures Schnorr BIP340 des demandes et factures vérifient la racine Merkle des champs, pas l’identité du commerçant. [BOLT 12 — Negotiation protocol]
Le portefeuille compare les champs repris d’invoice_request avec invoice, montant, chaîne et signature. invoice_node_id doit correspondre à offer_issuer_id ou au blinded_node_id final concerné. Une signature tierce valide ne suffit pas. La structure Merkle permet des preuves sélectives de champs, pas la modification arbitraire des conditions signées. [BOLT 12 — Negotiation protocol]
L’invoice_amount Bitcoin est en msat ; 1000 msat valent un satoshi. offer_currency peut indiquer une autre devise selon ISO 4217 ; USD utilise par exemple les cents. Quantité et conversion lors de l’émission influencent le prix. Si invreq_amount est fixé, la facture doit correspondre ; sinon, on vérifie la plage autorisée. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
offer_paths transporte la demande ; invoice_paths transporte le paiement. Une invoice actuelle doit contenir des blinded paths et l’invoice_blindedpay correspondant, même pour un chemin direct au destinataire. L’aveuglement limite l’exposition de la topologie sans promettre anonymat total, disponibilité ou liquidité. Demander une facture ne requiert pas de serveur de paiement HTTPS ordinaire. [BOLT 12 — Negotiation protocol] [BOLT 4 — Route blinding]
offer_absolute_expiry limite l’offre. invoice_created_at et invoice_relative_expiry limitent la facture précise ; sans le second champ, 7200 secondes s’appliquent. Une offre réutilisable ne rend pas ses factures éternelles. Les bits pairs obligatoires inconnus sont rejetés ; les impairs inconnus sont ignorés. [BOLT 12 — Negotiation protocol]
Pour rembourser, celui qui souhaite envoyer l’argent peut publier invoice_request sans offer. Le bénéficiaire répond avec sa propre invoice ; le payeur doit vérifier le destinataire prévu, hors protocole si nécessaire. C’est un nouveau paiement, pas l’annulation du précédent. Scanner une demande ne prouve ni un droit ni une autorisation de paiement. [BOLT 12 — Negotiation protocol]
Conservez invoice, état du paiement et preimage correspondant. Le preimage prouve le règlement de la facture sans identifier à lui seul la personne qui paie. Si la réponse est perdue, vérifiez l’état avant de repayer. Prendre en charge les offres ne signifie pas gérer chaque extension ou paiement récurrent automatique ; vérifiez séparément réception, envoi et autorisations de l’application. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
Pour une vision complète, lisez aussi BOLT 11, Lightning Network, Lightning Routing, Confidentialité de Bitcoin, Satoshi, LNURL. Cette entrée est également citée par BOLT 11, LNURL.