Offre BOLT12

Une offre est une demande de paiement qui survit au paiement, si bien qu'un seul code imprimé sert à chaque client. Les offres ne portent ni signature ni somme de contrôle, et leurs champs occupent les types TLV 2 à 22, volontairement assez courts pour la caméra d'un téléphone d'entrée de gamme. Si vous recevez du bitcoin, c'est la différence entre un code que vous imprimez une fois et la facture qu'il génère, qui expire 7200 secondes plus tard.

Comment cela fonctionne

Une offre BOLT12 est une suite d'enregistrements de type, longueur et valeur écrits avec le préfixe lisible par un humain lno, un séparateur 1, puis des caractères de style bech32 portant ces enregistrements dans l'ordre.

Il n'y a pas de somme de contrôle de six caractères à la fin. La spécification l'abandonne au motif que les codes QR portent leurs propres sommes de contrôle, et qu'une offre corrompue produit une chaîne impossible à analyser plutôt qu'un paiement perdu. Les offres longues peuvent être découpées avec un signe plus, éventuellement suivi d'un espace, pour survivre au collage dans un champ de texte à limite de caractères, et un lecteur doit retirer le signe plus et l'espace avant de décoder. Un émetteur doit tout écrire en minuscules ou tout en majuscules, et choisir les majuscules pour les codes QR.

Les champs eux-mêmes sont numérotés. offer_chains est 2, offer_metadata 4, offer_currency 6, offer_amount 8, offer_description 10, offer_features 12, offer_absolute_expiry 14, offer_paths 16, offer_issuer 18, offer_quantity_max 20 et offer_issuer_id 22. Un émetteur doit rester dans les types 1 à 79, avec une seconde plage de 1000000000 à 1999999999 réservée aux expérimentations. Rien dans cette liste n'est une signature, et c'est délibéré : signer allongerait la chaîne sans bénéfice, car chaque champ autre que la signature est recopié dans la demande qui suit, de sorte qu'une offre altérée ne produit simplement aucune facture.

Payer demande ensuite deux messages de plus. Votre portefeuille envoie une invoice_request, préfixe lnr, via un message oignon, en recopiant chaque champ de l'offre, y compris ceux qu'il ne comprend pas, et signe le résultat avec une signature BIP340 sur une racine de Merkle. L'émetteur répond par une facture signée. La construction de Merkle apparie la feuille de chaque champ avec une feuille de nonce, ce qui permet à un payeur de révéler plus tard un champ d'une facture contestée sans exposer ses voisins, ce qu'une signature BOLT11 sur toute la chaîne ne peut pas faire.

Deux de ces trois messages s'inversent pour les remboursements et les distributeurs automatiques. Un marchand publie une invoice_request indiquant un montant qu'il veut envoyer, vous répondez par une facture, et le marchand confirme l'invoice_node_id avant de payer.

Pourquoi cela compte quand vous achetez du bitcoin

Une offre change la façon dont vous publiez un moyen d'être payé, et ne change rien du tout à ce que coûte le fait d'être payé.

Prenez l'avis Phoenix sur ce site. ACINQ publie une grille tarifaire plutôt que de vous laisser la découvrir : envoyer via Lightning coûte 0,4 % plus 4 satoshis, recevoir est gratuit quand vous avez déjà de la liquidité entrante, et recevoir quand le portefeuille doit passer on-chain pour faire de la place coûte 1 % plus les frais de minage, avec un nouveau canal à 1 000 satoshis. Distribuer une offre plutôt qu'une facture ne touche aucun de ces chiffres. Cela supprime l'étape où vous générez un nouveau code par payeur, pas l'étape où quelqu'un paie pour la liquidité.

Le gain de confidentialité est réel mais étroit. Une adresse Lightning achemine chaque demande de facture via un serveur web sur le domaine de quelqu'un, et cet opérateur voit les montants et le moment. Une offre achemine la demande via Lightning sous forme de message oignon, et offer_paths permet à un nœud dont tous les canaux sont privés de rester joignable sans publier du tout d'identifiant de nœud. Ce que cela ne vous achète pas, c'est la confidentialité vis-à-vis de votre propre fournisseur : notre avis Phoenix cite la FAQ d'ACINQ qui dit en toutes lettres qu'il connaît la destination finale et le montant des paiements.

L'avertissement pratique concerne le collage. Un champ de retrait sur une plateforme d'échange demande une facture Lightning, et une chaîne lno1 n'en est pas une. Strike, l'un des 63 enregistrements de plateformes d'échange ici, est natif Lightning et n'ajoute pas de frais propres sur les transferts vers plus de 100 pays, et c'est exactement le type de flux où deux formats se confondent. Aucun des 41 avis de portefeuilles ni des 63 enregistrements de plateformes d'échange sur ce site ne documente actuellement la prise en charge des offres comme fonctionnalité, alors traitez-la comme quelque chose à confirmer dans les notes de version de votre propre portefeuille plutôt qu'à supposer.

L'offre d'un stand de chapeaux, et la facture qu'elle devient

Un stand qui vend des chapeaux à 25 dollars écrit une offre avec offer_currency défini sur USD et offer_amount défini sur 2500.

C'est la règle de la spécification pour une devise autre que le bitcoin : un code ISO 4217 de trois lettres, et un montant dans l'unité de la devise ajusté par l'exposant ISO 4217, ce qui pour les dollars signifie des cents. Définir offer_amount rend offer_description obligatoire, car un payeur à qui on facture quelque chose de précis doit savoir de quoi il s'agit. S'il reste trois chapeaux, offer_quantity_max est 3, et si le stand n'a pas de limite fixe, c'est 0. Une valeur de 1 est explicitement autorisée, aussi étrange que cela paraisse, de sorte qu'un système de stock n'a jamais besoin d'un cas particulier pour le dernier article. offer_issuer pourrait indiquer hats@example.com Hat Stall, la spécification demandant un domaine d'abord puis un texte convivial après un espace.

Votre portefeuille lit cela, vous annonce 25 dollars, et envoie une invoice_request portant un invreq_quantity de 2 pour deux chapeaux, un invreq_payer_id, et éventuellement un invreq_payer_note. En retour arrive une facture avec un hachage de paiement, un horodatage de création, au moins un chemin aveuglé, et une estimation de frais par chemin couvrant les frais de base, les frais proportionnels, le delta CLTV et le plus petit et le plus grand HTLC qu'il transportera. Deux règles vous protègent ici. Votre portefeuille doit rejeter la facture si un champ des plages 0 à 159 ne correspond pas à ce qu'il a envoyé, et il doit vous avertir si le montant en millisatoshis diffère sensiblement de l'estimation en dollars donnée par l'offre. À moins que l'émetteur ne définisse invoice_relative_expiry, la facture doit être rejetée 7200 secondes après sa création.

Offre BOLT12 vs facture BOLT11

Une offre BOLT12 est une demande de demande de paiement ; une facture BOLT11 est la demande de paiement.

Le texte BOLT12 s'ouvre sur huit critiques de son prédécesseur, et celles qu'un payeur ressent sont celles-ci. Une facture BOLT11 est signée en entier, donc prouver un champ revient à révéler tous les autres. Ses montants lisibles par un humain, selon la spécification, se sont révélés épineux : le multiplicateur p était souvent mal géré, et le pico-bitcoin est plus difficile à compter que les satoshis. Son payment_secret n'a arrêté le sondage que tant que la facture restait privée entre payeur et bénéficiaire, ce qu'une facture publiée n'est pas. Et, selon les propres mots de la spécification, les factures doivent être données par utilisateur et sont activement dangereuses si deux tentatives de paiement sont faites pour le même utilisateur. Une offre répond aux quatre en n'étant pas du tout une facture.

Offre BOLT12 vs adresse Lightning

Une offre BOLT12 est une chaîne autonome ; une adresse Lightning est un nom que le serveur de quelqu'un résout pour vous.

Les deux sont réutilisables, c'est pourquoi on les confond. L'adresse dépend d'un domaine, d'un certificat et d'un opérateur qui maintient le service en marche, et elle cesse de fonctionner le jour où l'un des trois disparaît. L'offre dépend de la capacité des deux nœuds à parler les messages oignon et de rien d'autre, ce qui est une surface de défaillance plus petite, encore faut-il confirmer que votre propre portefeuille la prend en charge plutôt que de le supposer. L'adresse l'emporte pour ce qui est de se dire à voix haute. Une longue chaîne lno1 est un code QR, pas quelque chose que l'on prononce dans un microphone.