BOLT 12

Imaginez un café qui souhaite laisser un seul code sur le comptoir pour les contributions volontaires. Payer plusieurs fois la même facture BOLT 11 ordinaire poserait problème. BOLT 12 publie plutôt une offer. Le portefeuille du client envoie alors une invoice_request pour demander sa propre facture, et le destinataire répond par une nouvelle invoice. C’est seulement ensuite qu’elle peut être payée. Un QR imprimé peut ainsi servir à plusieurs personnes sans partager la même facture. Obtenir une facture, par exemple avec fetchinvoice, n’envoie pas encore d’argent. L’offre ne donne pas non plus au café l’autorisation de prélever d’autres paiements dans le portefeuille d’autrui. [1] [3] [4]

L’offre peut afficher un prix en bitcoin ou dans une autre monnaie. Le champ offer_currency utilise les codes ISO 4217 ; un montant en USD est par exemple exprimé en cents. La quantité et la conversion monétaire peuvent intervenir lors de la création de la facture. Le montant final en bitcoin, invoice_amount, est toutefois en millisatoshi, des millièmes de satoshi : 1000 msat = 1 sat. Le payeur doit connaître ce montant et les frais avant de payer, pas seulement le prix initial affiché. Si la demande fixe une invreq_amount précise, la facture doit la respecter. Sinon, le portefeuille vérifie la plage autorisée et devrait demander une nouvelle approbation en dehors de cette plage. Une conversion ne vaut pas accord invisible sur n’importe quel prix. [1] [3]

Le code imprimé peut rester sur le comptoir, mais l’offre peut elle-même expirer à offer_absolute_expiry. Chaque facture possède aussi son heure de création invoice_created_at et sa durée invoice_relative_expiry. Sans cette durée, la valeur par défaut est de 7200 secondes, soit deux heures. Une ancienne facture n’est donc pas un contact valable indéfiniment. Les portefeuilles doivent également comprendre les fonctions obligatoires annoncées dans les messages. Un bit pair inconnu indique une fonction requise et entraîne un refus ; un bit impair inconnu est facultatif et peut être ignoré. Il s’agit de compatibilité sûre, pas d’un obstacle à contourner en réécrivant le code à la main. [1]

Après le paiement, conservez la facture et le résultat du portefeuille. Les preuves de règlement comprennent aussi le preimage, une valeur secrète obtenue lorsque le paiement aboutit. Le portefeuille en calcule le hash, une valeur de contrôle, et le compare au hash de paiement de la facture. Avec la facture, cela permet de prouver son règlement, sans pour autant identifier la personne qui a payé. Si l’application se déconnecte ou perd la réponse, vérifiez l’état du paiement précédent avant de recommencer ; une nouvelle facture peut entraîner un autre paiement. Examinez tout aussi attentivement les promesses de paiements récurrents. Prendre en charge BOLT 12 ne signifie pas automatiquement prendre en charge toutes les extensions ni autoriser des prélèvements. Vérifiez séparément la réception de paiements par offres, le paiement des offres d’autrui et les droits accordés à une application connectée. [1] [3]

La demande de facture et le transfert utilisent le réseau à des fins différentes. offer_paths achemine le message de demande, tandis que invoice_paths fournit les chemins du paiement. BOLT 12 emploie des blinded paths, des chemins masquant une partie des informations de connexion au destinataire. Moins dévoiler l’organisation du réseau aide la confidentialité, sans promettre un anonymat total. Un chemin masqué ne garantit ni un destinataire disponible ni de la liquidité, c’est-à-dire assez de fonds du bon côté des canaux. Techniquement, une invoice actuelle doit inclure ces chemins et les paramètres invoice_blindedpay correspondants, même pour un trajet direct vers le destinataire. Demander une facture n’exige pas de serveur de paiement HTTPS classique. [1] [2]

Lorsqu’un marchand veut rembourser un client, le sens de l’échange s’inverse. Celui qui souhaite payer peut publier une invoice_request sans offer préalable. Le client, futur bénéficiaire, répond avec sa propre invoice que le marchand paiera. Cela n’efface ni n’annule le paiement initial : c’est un nouveau paiement dans l’autre sens. Le marchand doit vérifier que la facture appartient au destinataire prévu, parfois en communiquant hors du protocole. Scanner une demande ne prouve pas un droit au remboursement et n’autorise pas le transfert. Le procédé technique facilite l’échange ; il ne décide pas à qui l’argent revient. [1]

BOLT 12 stocke les données en TLV : chaque champ indique son type, sa longueur et sa valeur. Une offre textuelle commence par lno, une demande par lnr. Le jeu de caractères ressemble à Bech32, mais sans sa somme de contrôle finale. Cela ne dit pas à lui seul qui doit recevoir le paiement. L’offer n’est pas signée. Les signatures numériques BIP340 Schnorr permettent de vérifier la facture et la demande habituelle faite en réponse à une offre. Une demande indépendante publiée sans offre, par exemple pour un remboursement, ne porte pas de signature. La signature porte sur la racine d’une structure de Merkle : une valeur de contrôle calculée à partir de l’ensemble des champs concernés. On peut ainsi prouver certains champs sans toujours révéler tous les détails. Cela ne permet ni de modifier les conditions signées ni de prouver l’identité civile du commerçant. [1]

Le portefeuille doit établir qu’il a reçu une réponse à sa demande, et pas seulement une facture quelconque correctement signée. Il compare les champs repris de l’invoice_request avec l’invoice, ainsi que le réseau, le montant et la signature. La clé publique invoice_node_id doit correspondre à offer_issuer_id ; si l’offre utilise plutôt le chemin masqué concerné sans cet identifiant, le portefeuille vérifie son blinded_node_id final. C’est comme vérifier que l’addition concerne votre table, et pas seulement que son tampon est authentique. La structure de Merkle permet des preuves sélectives, mais ne dispense pas le portefeuille de vérifier toutes les conditions nécessaires. La facture valide d’un autre client ne devient pas la bonne parce que sa signature passe le contrôle. [1]