Lightning Address est un identifiant utilisateur@domaine dont un portefeuille obtient les paramètres LNURL-pay, puis une facture BOLT 11 précise. Les fonds ne sont pas envoyés par e-mail et le nom lui-même ne conserve aucun bitcoin.
LUD-16 emploie un username et un domaine, mais limite le nom aux minuscules a-z, aux chiffres 0-9 et à -_. ; le signe plus exige la prise en charge des tags par le service. La syntaxe habituelle des e-mails est plus large. Une boîte aux lettres ne garantit donc pas une Lightning Address, et un même nom ne prouve pas l’identité humaine du destinataire. [Lightning Address — LUD-16] [Lightning Address — Project overview]
Le portefeuille effectue un GET sur /.well-known/lnurlp/username du domaine, via HTTPS ou HTTP pour un service onion. La réponse est un payRequest selon LUD-06. Le domaine réel et son service sont déterminants ; la partie avant l’arobase n’est pas la clé publique d’un nœud. [Lightning Address — LUD-16]
La réponse fournit callback, metadata et les limites minSendable/maxSendable. Le payeur choisit amount en msat ; 1000 msat valent un satoshi. Le callback renvoie une facture dans pr, puis le portefeuille vérifie le montant avant de payer. Résoudre l’adresse ou recevoir une facture n’est pas un règlement. [LNURL — LUD-06 payRequest] [Lightning Address — Implementation guide]
La version récente de LUD-16 autorise facultativement @domaine comme raccourci de _@domaine, avec un chemin finissant par /_. Ni le service ni le portefeuille ne sont obligés de le prendre en charge. Un +tag accepté est transmis dans le chemin ; le service peut l’utiliser comme métadonnée text/tag. Un tag n’est ni une nouvelle clé Bitcoin ni une protection automatique de la vie privée. [Lightning Address — LUD-16]
LUD-16 exige text/identifier ou text/email dans metadata ; text/email correspond à une véritable adresse e-mail. Le text/plain de LNURL-pay reste également requis. Comparez le nom et la description affichés au domaine et au destinataire prévu. L’affirmation d’un service ne vérifie pas indépendamment l’identité d’une personne. [Lightning Address — LUD-16] [LNURL — LUD-06 payRequest]
Le service peut émettre les factures de son portefeuille ou utiliser un serveur passerelle relié à un nœud. Le format seul n’implique donc ni garde par un tiers ni autogarde. La passerelle a besoin des permissions nécessaires à sa fonction, pas automatiquement du contrôle illimité du portefeuille. Le responsable de l’endpoint peut influencer la facture reçue par le payeur. [Lightning Address — Implementation guide] [Lightning Address — Bridge server]
Un portefeuille peut payer une Lightning Address sans fournir d’adresse personnelle à ses utilisateurs. Recevoir nécessite un service web fonctionnel, l’émission d’une facture et la capacité d’accepter le paiement. Le nom lisible ne crée aucune liquidité entrante à lui seul. Des requêtes répétées peuvent révéler au fournisseur le destinataire et le calendrier des demandes. [Lightning Address — Implementation guide]
Un domaine personnel permet de rediriger l’endpoint vers un autre serveur ; BTCPay décrit notamment HTTP 301. Avec le domaine d’un tiers, conserver le nom dépend du fournisseur. Une seed ne restaure ni le contrôle DNS, ni les certificats, ni les associations de comptes. Après un changement de service, vérifiez à nouveau la résolution, la facture cible et la réception ; ne supposez pas que les anciens contacts se mettent automatiquement à jour. [BTCPay Server — Address redirection] [Lightning Address — Implementation guide]
Pour une vision complète, lisez aussi LNURL, BOLT 11, Lightning Network, Inbound Liquidity, Auto-garde, Confidentialité de Bitcoin. Cette entrée est également citée par LNURL, Inbound Liquidity, Confirmo, Strike.