Lightning Address es un identificador usuario@dominio del que una cartera obtiene parámetros LNURL-pay y después una factura BOLT 11 concreta. El dinero no se envía por correo electrónico y el nombre no guarda bitcoins.
LUD-16 usa username y dominio, pero limita el nombre a a-z minúsculas, dígitos 0-9 y -_.; el signo más solo se admite si el servicio soporta etiquetas. La sintaxis habitual del correo es más amplia. Un buzón no garantiza una Lightning Address y compartir el nombre no autentica al destinatario como persona. [Lightning Address — LUD-16] [Lightning Address — Project overview]
La cartera solicita mediante GET la ruta /.well-known/lnurlp/username del dominio, por HTTPS o HTTP en un servicio onion. La respuesta es un payRequest según LUD-06. Importan el dominio real y su servicio; la parte anterior a la arroba no es la clave pública de un nodo. [Lightning Address — LUD-16]
La respuesta ofrece callback, metadata y los límites minSendable/maxSendable. El pagador elige amount en msat; 1000 msat equivalen a un satoshi. El callback devuelve una factura en pr y la cartera comprueba que el importe coincida antes de pagar. Consultar la dirección o recibir una factura no significa liquidación. [LNURL — LUD-06 payRequest] [Lightning Address — Implementation guide]
La versión más reciente de LUD-16 permite opcionalmente @dominio como abreviatura de _@dominio y una ruta terminada en /_. Ni el servicio ni la cartera están obligados a admitirlo. Un +tag admitido se envía en la ruta; el servicio puede usarlo como metadata text/tag. Una etiqueta no es una nueva clave Bitcoin ni protección automática de la privacidad. [Lightning Address — LUD-16]
LUD-16 exige text/identifier o text/email en metadata; text/email corresponde a una dirección de correo real. También sigue siendo obligatorio text/plain de LNURL-pay. Compare el nombre y la descripción mostrados con el dominio y el destinatario previsto. La afirmación del servicio no es una verificación independiente de identidad humana. [Lightning Address — LUD-16] [LNURL — LUD-06 payRequest]
El servicio puede emitir facturas de su cartera o usar un servidor puente conectado a un nodo. Por eso el formato no implica custodia ni autocustodia. El puente necesita permisos para su función, no automáticamente control ilimitado de la cartera. Quien controla el endpoint puede influir en la factura que recibe el pagador. [Lightning Address — Implementation guide] [Lightning Address — Bridge server]
Una cartera puede pagar a una Lightning Address sin proporcionar una dirección propia al usuario. Recibir requiere un servicio web operativo, crear una factura y poder aceptar el pago. El nombre legible no genera liquidez entrante por sí solo. Las consultas repetidas pueden revelar al proveedor el destinatario y los tiempos. [Lightning Address — Implementation guide]
Un dominio propio permite redirigir el endpoint a otro servidor; BTCPay describe, por ejemplo, HTTP 301. En un dominio ajeno, conservar el nombre depende del proveedor. La semilla no restaura el control de DNS, los certificados ni la asignación de cuentas. Tras cambiar de servicio, vuelva a verificar la consulta, la factura de destino y la recepción; no suponga que los contactos antiguos se actualizan automáticamente. [BTCPay Server — Address redirection] [Lightning Address — Implementation guide]
Para obtener la imagen más completa, lee esta entrada junto con LNURL, BOLT 11, Lightning Network, Inbound Liquidity, Autocustodia, Privacidad en Bitcoin. También enlazan con esta entrada LNURL, Inbound Liquidity, Strike, Satsback.