LNURL est une famille de procédures applicatives Lightning optionnelles décrites dans les LUD. Elle transmet paramètres et requêtes entre portefeuille et service ; ni règle de consensus Bitcoin ni autorisation universelle.
LNURL comprend payRequest pour payer, withdrawRequest pour retirer et login pour se connecter, avec d’autres extensions. Les portefeuilles implémentent différents sous-ensembles de LUD. « Compatible LNURL » ne signifie pas que toutes les opérations fonctionnent ni que leur approbation a le même effet. [LNURL — LUD index] [Lightning Labs — LNURL glossary]
LNURL de base, selon LUD-01, encode une URL HTTPS ou onion en Bech32. Ce n’est ni du chiffrement ni une facture BOLT 11. Le tag dans l’URL ou dans le JSON reçu après GET détermine le type. Le portefeuille doit identifier domaine et opération ; l’apparence du QR ne prouve pas le destinataire. [LNURL — LUD-01 encoding]
payRequest renvoie callback, minSendable, maxSendable et metadata. Limites et amount choisi sont en msat ; 1000 msat valent un satoshi. Après approbation des conditions, le portefeuille demande une facture dans pr et vérifie son montant avant paiement. Le lien statique ne prouve pas le règlement. [LNURL — LUD-06 payRequest]
Metadata est une chaîne contenant un tableau JSON avec une entrée text/plain obligatoire ; les autres types sont optionnels. Lire la description avec le domaine et le montant. LNURL de base interprète le corps JSON, pas le seul code HTTP ; ERROR ou la réception d’une facture pr ne constituent pas un paiement réussi. [LNURL — LUD-01 encoding] [LNURL — LUD-06 payRequest]
withdrawRequest renvoie k1, callback et les limites minWithdrawable/maxWithdrawable en msat. Votre portefeuille crée une facture de réception, transmise comme pr au service qui doit la payer. Status OK accuse réception de la demande ; le portefeuille attend encore les fonds. Un lien de retrait peut porter une autorisation : ce n’est pas un contact public de paiement. [LNURL — LUD-03 withdrawRequest]
LNURL-auth avec tag login utilise k1 et un linkingKey propre au domaine. Après consentement, le portefeuille signe avec ECDSA sur secp256k1 sans envoyer sa graine au service. Action peut être inscription, connexion, association ou autre autorisation. Signer le défi n’est ni payer des bitcoins ni prouver automatiquement l’identité d’une personne. [LNURL — LUD-04 authentication]
HTTPS protège le transport, mais le service peut connaître requêtes et horaires. Les usages répétés peuvent être liés. Auth dérive la clé à partir du domaine complet ; changer de sous-domaine change linkingKey et peut donner un autre compte. La portabilité entre portefeuilles n’est pas garantie, leurs dérivations diffèrent. LNURL ne détermine pas la garde des bitcoins. [LNURL — LUD-01 encoding] [LNURL — LUD-04 authentication]
LUD-21 optionnel ajoute une URL verify ; sa réponse distingue settled true/false et peut fournir preimage. Status OK seul ne signifie pas settled true. Vérifiez le lien avec la facture précise et l’état du portefeuille. Si la réponse est perdue, ne repayez pas aveuglément ; disponibilité, liquidité entrante et portée du consentement restent distinctes. [LNURL — LUD index] [LNURL — LUD-21 verification]
Pour une vision complète, lisez aussi BOLT 11, BOLT 12, Lightning Network, Lightning Address, Confidentialité de Bitcoin, Satoshi. Cette entrée est également citée par BOLT 12, Lightning Address, Confirmo.