Factures : BOLT11 et BOLT12

Curiosité

1. Pourquoi une demande de paiement qui expire au bout d’une heure oblige-t-elle les commerçants à la régénérer constamment ?
2. Comment un code QR statique peut-il rester valide pendant des années tout en générant des factures uniques et sécurisées pour chaque transaction ?
3. Quels champs de données précis permettent à un portefeuille de vérifier qu’une facture n’a pas été altérée avant d’envoyer des fonds ?

Explorer

1. Une facture BOLT11 est une chaîne bech32 commençant par « lnbc » qui regroupe tous les paramètres de paiement nécessaires. Elle encode un montant facultatif (en bitcoin, avec une lettre multiplicatrice, jusqu’à des fractions de satoshi), un hash de paiement spécifique dérivé d’une préimage secrète et un horodatage d’expiration fixé par défaut à une heure. La clé publique du nœud bénéficiaire identifie la destination, tandis que des indications de route facultatives guident le payeur si aucun canal direct n’est disponible. L’ensemble de la chaîne est signé par le bénéficiaire, ce qui en garantit l’intégrité.
2. Cette architecture rend les factures BOLT11 strictement à usage unique. Une fois que l’expéditeur a payé le hash de paiement associé, la facture est réglée et ne peut plus être utilisée. La payer deux fois n’est pas sûr : après le premier paiement, la préimage est connue de tous les nœuds de cette route, de sorte que n’importe lequel de ces nœuds se trouvant aussi sur la route du second paiement pourrait s’en emparer. Cette contrainte impose des codes QR dynamiques dans le commerce de détail, où les commerçants doivent générer une nouvelle chaîne pour chaque client, ce qui complique le matériel de point de vente.
3. Les développeurs de la communauté ont levé cette friction grâce à LNURL et aux adresses Lightning, qui s’appuient sur des serveurs web externes. L’utilisateur scanne une URI statique pointant vers un endpoint de serveur ; le portefeuille récupère alors une nouvelle facture BOLT11 auprès de ce serveur avant d’initier le paiement. Cela dissocie l’adresse publique des données propres à chaque transaction, ce qui permet à un seul lien de servir un nombre illimité de paiements tout en conservant, en arrière-plan, la sécurité de factures uniques à usage unique.
4. Les « offers » BOLT12, conçues par Rusty Russell et ajoutées à la spécification en 2024, intègrent ce flux au protocole. Ces codes de paiement réutilisables commencent par « lno » et servent d’identifiants statiques pour un nœud bénéficiaire. Une fois l’offre scannée, le portefeuille du payeur envoie un message en oignon (onion message) directement via le réseau Lightning afin d’obtenir une nouvelle facture auprès du créateur de l’offre. Cela supprime la dépendance aux serveurs web externes et intègre la génération des demandes au cœur du protocole.
5. Les offres BOLT12 prennent en charge des fonctionnalités absentes de BOLT11, notamment des flux dans lesquels le commerçant paie l’utilisateur, comme les remboursements ou les retraits (les paiements récurrents avaient été prévus dans un brouillon, mais retirés de la spécification fusionnée). Les offres peuvent également utiliser des chemins masqués (blinded paths) pour cacher le nœud destinataire au sein du graphe des canaux, au lieu de publier sa clé publique. Cette conception limite les fuites de confidentialité par rapport aux factures classiques, qui exposent directement des indications de routage ou des adresses de repli.
6. Les paiements spontanés se passent entièrement de facture grâce aux protocoles keysend ou AMP (Atomic Multi-Path), avec lesquels l’expéditeur envoie des fonds vers une clé de nœud connue sans demande préalable. Pour vérifier par vous-même, collez n’importe quelle facture Lightning dans un décodeur BOLT11 public. Repérez le préfixe lisible par un humain, le montant, le hash de paiement, le délai d’expiration et la signature du bénéficiaire. Comparez avec une chaîne « lno », qui ne contient aucun hash de paiement, mais uniquement ce dont le payeur a besoin pour demander une facture : l’ID du nœud ou des chemins masqués menant à celui-ci.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• BOLT #11: Payment Requests (Lightning Network Specification)
• BOLT #12: Offers (Lightning Network Specification)
• A. M. Antonopoulos, O. Osuntokun & R. Pickhardt, Mastering the Lightning Network (2021)