BOLT 11 est le standard de facture Lightning signée et encodée en Bech32. Elle contient le payment hash, les informations du destinataire et les conditions du paiement : une demande, pas une preuve de paiement réussi.
Bech32 dispose d’une somme de contrôle contre les erreurs de transcription ; ce n’est pas du chiffrement. Une signature ECDSA sur secp256k1 protège le contenu et le lie à la clé du destinataire, pas à une personne vérifiée. Contrairement aux adresses Bech32, BOLT 11 n’a pas de limite de 90 caractères. Un QR peut utiliser les majuscules ; la casse mixte est invalide. [BOLT 11 — Invoice protocol]
lnbc désigne mainnet, lntb testnet, lntbs signet et lnbcrt regtest. Le montant est en BTC avec le multiplicateur m, u, n ou p. Avec p, le dernier chiffre doit être 0 pour obtenir des msat entiers ; 1000 msat valent un satoshi. Sans montant, le payeur le fournit ; cela ne signifie pas un paiement nul. [BOLT 11 — Invoice protocol]
Le champ p contient le payment hash : SHA256 du payment preimage. Le champ s contient payment_secret, exigé par le destinataire dans la dernière partie du paiement acheminé. Le secret n’est ni le preimage ni la graine du portefeuille. BOLT 11 actuel exige les deux champs ; lire le secret de la facture ne prouve pas le paiement. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
La facture contient exactement une variante : texte d ou hash h d’une description externe. Pour h, le portefeuille doit vérifier le SHA256 de la description fournie ; le hash seul n’explique pas l’achat. La signature lie contenu et clé sans certifier la promesse du commerçant. Le texte décodé doit être affiché sans danger comme donnée. [BOLT 11 — Invoice protocol]
Timestamp plus x fixe l’expiration ; sans x, la durée par défaut est de 3600 secondes. Le champ c est min_final_cltv_expiry_delta du dernier HTLC en blocs, pas une autre durée en secondes ; en son absence, au moins 18 blocs s’appliquent. L’expiration n’annule pas un paiement terminé. [BOLT 11 — Invoice protocol]
Le champ 9 indique les fonctions obligatoires et optionnelles. Un bit pair inconnu impose le rejet ; un bit impair inconnu est ignoré. Les dépendances connues doivent être satisfaites. Basic MPP n’est permis que si basic_mpp est proposé. Répartir le paiement ne crée pas plusieurs factures indépendantes. [BOLT 11 — Invoice protocol] [BOLT 9 — Assigned feature flags]
Le champ r ajoute des routing hints vers le destinataire ; il peut révéler des clés de nœuds, des identifiants de canaux et des paramètres de frais. Il ne prouve pas la liquidité actuelle. Le champ optionnel f peut proposer une adresse on-chain, autre moyen de paiement avec ses frais et confirmations. La facture n’est donc ni un contact privé ni un contact réutilisable indéfiniment. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
Après l’envoi, distinguez attente et achèvement. Conservez la facture et le preimage correspondant comme éléments de règlement, pas seulement une capture du QR. Si la réponse est perdue, vérifiez d’abord l’état dans le portefeuille. Une nouvelle facture ou un autre moyen peut provoquer un autre paiement ; le format seul ne protège pas universellement contre les répétitions. [BOLT 4 — Onion routing] [Core Lightning — Payment result]
Pour une vision complète, lisez aussi Lightning Network, HTLC, BOLT 12, Nostr Wallet Connect, Satoshi. Cette entrée est également citée par Nostr Wallet Connect, BOLT 12, LNURL, Lightning Address.