BOLT 11 est un standard de demande de paiement pour Lightning Network, couramment appelé facture Lightning. Il indique au portefeuille où payer et à quelles conditions. La demande prend la forme d’une longue chaîne de texte ou d’un QR code ; ce n’est ni un solde, ni un contact permanent, ni un reçu.
Anna achète un livre numérique. Au lieu de coordonnées bancaires, la boutique affiche une facture Lightning que son portefeuille décode. Anna n’a pas à comprendre la longue chaîne : avant de confirmer, elle vérifie le montant, l’objet et les frais. Certaines factures laissent le montant libre, par exemple pour une contribution volontaire. C’est alors le payeur qui le saisit ; une absence de montant ne signifie pas un paiement nul. Pour aller plus loin, lnbc désigne le réseau principal ; lntb, testnet ; lntbs, signet ; et lnbcrt, regtest, ces derniers étant des environnements de test. Le montant encodé est exprimé en BTC avec éventuellement un multiplicateur m, u, n ou p, pas directement en satoshi. Avec p, il doit se terminer par 0 pour correspondre à des millisatoshi entiers : 1000 msat = 1 sat. [1]
La description relie la demande technique à un motif concret, comme le livre d’Anna. La facture contient soit le texte dans le champ d, soit son empreinte numérique dans h. Cette empreinte est calculée avec SHA256 ; le portefeuille doit vérifier qu’une description fournie séparément produit le même résultat. Cette courte valeur de contrôle calculée à partir du texte s’appelle un hash. L’empreinte seule ne permet pas de lire la commande. Une signature valide lie la description à la clé du destinataire, mais ne promet pas que le marchand livrera le livre. Les développeurs doivent aussi traiter cette description comme un texte extérieur : l’afficher prudemment comme des données, jamais l’exécuter comme du code. [1]
Anna laisse sa commande ouverte et revient plus tard. Si le portefeuille indique que la facture a expiré, elle doit en demander une nouvelle. L’échéance est calculée à partir de l’heure de création timestamp et de la durée x. En l’absence de x, la durée par défaut est de 3600 secondes, soit une heure. L’expiration n’annule pas un paiement déjà terminé. Le champ c, nommé min_final_cltv_expiry_delta, règle autre chose : la marge temporelle du dernier paiement conditionnel, un HTLC, sur le trajet. Un HTLC conditionne le règlement à la présentation du bon secret dans les délais. Cette marge se mesure en blocs, pas en secondes de validité ; sans c, le payeur utilise au moins 18 blocs. Ces deux durées ne doivent pas être confondues. [1]
Un paiement Lightning emprunte des canaux de paiement. Dans un canal, deux parties actualisent la répartition des fonds sans inscrire chaque paiement courant dans la blockchain principale de Bitcoin. Pour que le paiement aboutisse, il faut un chemin utilisable et suffisamment de fonds du bon côté de chaque canal : de la liquidité. Le champ r peut fournir des routing hints, des indications pour la dernière partie du trajet. Elles aident à atteindre le destinataire sans décrire sa capacité disponible en temps réel. Elles peuvent aussi révéler des clés publiques de nœuds, des identifiants de canaux et des paramètres de frais. Ne considérez donc pas la facture complète comme privée. Le champ facultatif f peut proposer une adresse Bitcoin classique en solution de repli. La payer passe par la chaîne principale, avec ses propres frais et confirmations. Ce n’est pas simplement un autre bouton pour le même mode d’envoi. [1] [2] [5]
Un QR code scanné ou une facture reçue n’est pas un reçu. Après l’envoi, consultez le résultat dans le portefeuille : en attente ne veut pas dire terminé. Le règlement est également attesté par le bon preimage, une valeur secrète dont le hash doit correspondre au hash de paiement de la facture. Conservez les deux comme éléments de preuve du paiement, pas comme garantie de livraison. Si l’application se déconnecte ou perd la réponse, vérifiez d’abord l’état du paiement initial. Demander immédiatement une nouvelle facture ou payer l’adresse de repli peut entraîner un second paiement. Certains portefeuilles reconnaissent les nouvelles tentatives, mais le format n’offre aucune protection universelle entre applications et moyens de paiement. [2] [4]
La longue chaîne utilise l’encodage Bech32. Sa somme de contrôle aide à repérer les erreurs de transcription ; ce n’est pas du chiffrement et elle ne cache pas le contenu. La signature numérique ECDSA sur secp256k1 joue un autre rôle : vérifier que les données correspondent à la clé du destinataire et n’ont pas été modifiées ensuite. Elle ne vérifie ni l’identité civile ni l’honnêteté de la personne derrière cette clé. Contrairement aux adresses Bitcoin Bech32, BOLT 11 peut dépasser 90 caractères. Les majuscules conviennent aux QR codes, mais une chaîne valide ne doit pas mélanger majuscules et minuscules. En pratique, la personne scanne ou copie ; son portefeuille effectue ces contrôles. [1]
Le payment hash est l’empreinte numérique d’une valeur secrète, le payment preimage, calculée avec SHA256 et placée dans p. Au règlement, le payeur obtient le preimage et vérifie que l’empreinte correspond. Le champ s contient quant à lui payment_secret. Le payeur le lit déjà dans la facture et le transmet au destinataire dans la dernière partie du paiement acheminé ; il contribue à protéger celui-ci contre les sondages des nœuds intermédiaires. Secret n’est ni le preimage ni le seed du portefeuille. Le lire dans un QR code ne prouve donc pas un paiement et ne permet pas de restaurer le portefeuille. BOLT 11 exige actuellement p et s. Malgré leurs noms proches, ces valeurs servent à identifier le paiement, transmettre un renseignement nécessaire et attester le règlement. [1] [2]
Les portefeuilles doivent également savoir s’ils prennent en charge le paiement demandé. Le champ 9 contient des indicateurs de fonctions. Un bit pair inconnu signale une fonction obligatoire et impose de refuser le paiement ; un bit impair inconnu est facultatif et peut être ignoré. Les dépendances connues entre fonctions doivent aussi être respectées. Basic MPP, par exemple, divise un paiement en plusieurs parties réunies chez le destinataire. Il ne peut être utilisé que si la facture propose basic_mpp. Cela ne crée pas plusieurs factures indépendantes ni une raison de payer à nouveau chaque partie. Pour débuter, retenez ceci : ne contournez pas un message de fonction non prise en charge en modifiant la facture ; réglez d’abord la compatibilité des portefeuilles. [1] [3]
Pour une vision complète, lisez aussi Lightning Network, HTLC, BOLT 12, Nostr Wallet Connect, Satoshi, SHA-256. Cette entrée est également citée par Nostr Wallet Connect, BOLT 12, LNURL, Lightning Address.