Lightning Address

Anna souhaite recevoir des contributions pour son podcast. Au lieu d’envoyer une nouvelle longue facture à chaque auditeur, elle publie une Lightning Address. L’exemple anna@example.com est facile à retenir : la partie avant l’arobase désigne le destinataire auprès du service, celle qui suit désigne le domaine qui répond au portefeuille. La ressemblance avec l’e-mail est voulue, mais l’argent ne circule pas par courrier électronique. Une adresse e-mail existante n’est pas automatiquement une Lightning Address, et le nom seul ne prouve pas qui la possède. Vérifiez-le auprès du créateur que vous souhaitez soutenir. [1] [6]

L’auditeur saisit le nom dans un portefeuille compatible. Celui-ci demande au service une description et la plage de montants autorisés. Une fois le domaine, la description et le montant choisi vérifiés par l’utilisateur, il demande une facture BOLT 11 précise et en contrôle le montant avant de payer. Obtenir une facture n’est pas encore payer. Ce processus s’appelle LNURL-pay. Le service fournit un callback, l’adresse où demander la facture, des metadata descriptives et les limites minSendable et maxSendable. amount s’exprime en msat, des millièmes de satoshi : 1000 msat = 1 sat. La facture arrive dans le champ pr. [2] [3]

Anna peut utiliser un service qui gère son portefeuille ou relier le nom à son propre nœud Lightning, le logiciel qui traite ses paiements. L’adresse ne révèle pas la différence. Un endpoint web, le point où le serveur répond au portefeuille, peut passer par un serveur relais pour demander une facture au nœud. Cet intermédiaire ne garde pas nécessairement les fonds : cela dépend de l’architecture et des autorisations. Contrôler les réponses du serveur reste néanmoins important ; qui peut les remplacer peut présenter une autre facture au payeur. Posséder un domaine ne garantit pas à lui seul la self-custody, c’est-à-dire le contrôle de ses propres clés. [3] [4]

Un portefeuille peut envoyer vers une Lightning Address sans fournir à son utilisateur une adresse de réception personnelle. Recevoir exige aussi un service web disponible, la création d’une facture et la capacité de recevoir le paiement sur Lightning Network. Les paiements passent par des canaux : des connexions entre participants dans lesquelles la répartition des fonds entre les deux côtés évolue. Il faut notamment de l’Inbound Liquidity : des fonds de l’autre côté des canaux, qui peuvent passer au destinataire pendant le paiement. Un nom facile à retenir ne crée pas cette liquidité. Si l’adresse se charge mais que le paiement échoue, le nom n’est pas forcément en cause. Distinguez la réponse du site, la facture obtenue et la réception confirmée des fonds. [3] [5]

Avec votre propre domaine, vous pouvez changer le serveur chargé des paiements tout en conservant le nom connu des auditeurs. La documentation de BTCPay montre une redirection de l’endpoint par HTTP 301 : la requête web part ailleurs, sans déplacer de bitcoins. Vous n’avez pas forcément ce contrôle sur un nom hébergé sur le domaine d’un tiers. La Seed Phrase, les mots de récupération du portefeuille, ne garantit pas à elle seule de retrouver l’accès au compte du service. Elle ne sauvegarde pas non plus l’administration du domaine ni les réglages du DNS, le système qui indique où ce domaine mène. Après un changement, vérifiez la bonne facture et un paiement d’essai réellement reçu, pas seulement l’ouverture de l’adresse. Vos anciens contacts ne découvrent pas automatiquement un nouveau nom. [5] [3]

LUD-16 décrit la transformation du nom en requête web GET, une demande de données. Le portefeuille interroge le domaine au chemin /.well-known/lnurlp/username, en remplaçant username par le nom d’utilisateur. Il utilise HTTPS sur le web ordinaire et HTTP pour un domaine onion. La réponse payRequest poursuit le processus défini par LUD-06. HTTPS protège la connexion contre les altérations en transit, sans prouver l’honnêteté du service. Celui-ci traite les requêtes et connaît le destinataire de la facture ; le nom lisible n’apporte donc pas d’anonymat à lui seul. [1] [2]

LUD-16 autorise dans le nom d’utilisateur les minuscules a-z, les chiffres 0-9 et -_. ; l’e-mail ordinaire accepte davantage de caractères. Le raccourci facultatif @domain désigne le destinataire par défaut _@domain au chemin /.well-known/lnurlp/_, mais le portefeuille ou le service peuvent ne pas le prendre en charge. Le complément +tag n’est pas universel non plus. Un service compatible peut s’en servir pour distinguer l’objet d’une contribution et l’indiquer dans text/tag. Ce n’est ni une nouvelle clé privée ni une garantie de confidentialité. Au quotidien, reprenez le nom exact publié par le destinataire. [1]

Les métadonnées sont des renseignements complémentaires échangés entre portefeuille et service au format structuré JSON. Dans LNURL-pay, elles comprennent text/plain, une courte description du paiement. LUD-16 ajoute text/identifier pour l’associer au nom, ou text/email si ce nom correspond à une véritable adresse e-mail. Le portefeuille peut ainsi montrer à quoi le paiement se rapporte. Ce sont toujours des renseignements fournis par le service, pas une vérification indépendante de l’identité civile d’Anna. Vérifier l’adresse initialement obtenue, le domaine et le montant reste donc une précaution utile. [1] [2]