LNURL

Imaginons Anna qui scanne un code pour soutenir un auteur, puis un autre pour utiliser un bon, et enfin un troisième pour se connecter à un site. Le geste est identique, mais ce qu’elle autorise change à chaque fois. LNURL distingue ces tâches : payRequest sert à payer, withdrawRequest à retirer des fonds et login à se connecter. Les documents LUD décrivent chaque procédure. Ce sont des conventions facultatives entre applications, pas des modifications des règles de Bitcoin. Un portefeuille qui en prend une en charge ne prend pas nécessairement en charge les autres. [1] [7]

Avec payRequest, le service renvoie une description et une plage de montants autorisés. Anna vérifie le domaine — le nom du service dans son adresse web —, lit la description et choisit sa contribution. Une fois les conditions acceptées, le portefeuille demande une facture Lightning BOLT 11 précise et vérifie son montant avant de la payer. Il utilise l’adresse callback, les limites minSendable et maxSendable et la description metadata ; le montant est envoyé dans amount et la facture arrive dans pr. Les montants sont exprimés en msat, des millièmes de satoshi : 1000 msat = 1 sat. D’autres personnes peuvent utiliser le même QR public, mais le scanner ne confirme pas un paiement. [3]

Avec withdrawRequest, le sens du transfert s’inverse. Anna souhaite retirer un solde du service, pas lui verser de l’argent. Son portefeuille crée donc une facture de réception que le service doit payer. Celui-ci fournit un identifiant k1, une adresse callback et les limites minWithdrawable et maxWithdrawable en msat ; après accord, le portefeuille transmet sa facture dans pr. La réponse OK indique que le service a accepté la demande, pas qu’Anna a reçu l’argent. Le portefeuille attend encore le paiement entrant. Un code de retrait peut fonctionner comme un bon au porteur : ne le publiez pas comme une simple adresse destinée à recevoir des paiements. [4]

Sur un autre site, Anna choisit LNURL-auth. Le portefeuille affiche le domaine et l’objet de la demande portant le tag login. Avec son accord, il signe un défi à usage unique k1 avec la clé privée propre à ce domaine, linkingPrivKey. Il transmet au service la signature et la clé publique correspondante, linkingKey, qui permet de vérifier la signature. La clé privée reste secrète. Le service peut reconnaître le détenteur lorsqu’il revient, mais cette vérification ne révèle pas à elle seule son identité réelle. Le portefeuille ne transmet ni son seed, la valeur secrète de départ servant à dériver les clés, ni sa Seed Phrase, les mots de récupération. Il s’agit techniquement d’une signature ECDSA sur secp256k1. Le champ action peut désigner une inscription, une connexion, une association de comptes ou une autre autorisation : il faut donc lire toute la confirmation. Signer ce défi n’est pas en soi un paiement en bitcoins. [5]

La demande, la réponse du service et le transfert effectif sont des étapes distinctes. Si Anna perd sa connexion, elle vérifie d’abord le paiement initial dans son portefeuille. Une nouvelle tentative avec une nouvelle facture peut entraîner un second paiement. La procédure facultative LUD-21 ajoute une adresse verify pour consulter une facture précise : settled true signale son règlement, settled false indique qu’elle ne l’est pas encore. OK ne suffit pas. La réponse peut contenir un preimage, la valeur secrète d’origine associée au paiement. Le portefeuille en calcule le hash, une valeur de contrôle, et le compare au hash de paiement de la bonne facture. Une valeur secrète quelconque ne suffit donc pas : elle doit correspondre à ce paiement précis. Vérifier le résultat ne garantit ni un service disponible ni la liquidité entrante, c’est-à-dire la capacité d’acheminer l’argent vers le portefeuille destinataire. [6] [3] [4]

HTTPS protège le transport entre le portefeuille et le service, pas contre le service lui-même. Celui-ci peut observer les demandes, leurs horaires et les usages répétés. Pour la connexion, le nom de domaine complet compte également : changer de sous-domaine peut produire une autre linkingKey et donc un utilisateur différent aux yeux du site. Passer à un autre portefeuille ne garantit pas non plus de retrouver le même compte, car les applications dérivent les clés différemment. Avant un changement important, vérifiez la récupération de cet accès précis. LNURL ne détermine pas qui détient les clés des bitcoins ; cela dépend du portefeuille et du service. [2] [5]

La procédure de base LUD-01 représente une URL HTTPS ou onion au format Bech32. C’est un encodage, pas un chiffrement de l’adresse ni une facture BOLT 11. Le portefeuille lit le tag directement dans le lien ou effectue une requête web GET pour obtenir des données et identifie l’opération dans une réponse JSON. Ce format donne aux données des noms et une structure lisibles par l’application. L’image QR n’établit donc pas l’identité du destinataire. Ce sont le contenu du lien, puis le domaine, l’action et les conditions affichés qui comptent. [2]

Dans le parcours de paiement, metadata est une chaîne de texte contenant un tableau JSON. Celui-ci doit comporter une description text/plain ; les autres types sont facultatifs. Le portefeuille doit la présenter avec le domaine et le montant pour que la personne comprenne son accord. LNURL de base interprète le corps JSON de la réponse, pas simplement le code de statut HTTP. Un serveur qui répond n’a donc pas forcément accepté la demande : sa réponse peut contenir ERROR. De même, une facture reçue dans pr n’est pas encore payée. Une application ne devrait pas ramener ces situations distinctes à une seule coche verte. [2] [3]