LNURL y Lightning Address

El problema que LNURL resuelve

Las invoices BOLT 11 son poderosas pero incómodas: cada pago requiere que el receptor genere una nueva invoice, que debe transmitirla manualmente al emisor, y que esta se use antes de expirar. Este flujo rompe muchos casos de uso naturales:

• Donaciones públicas donde no hay comunicación directa emisor-receptor.
• Puntos de venta donde el cliente no puede esperar a que el comercio genere invoice.
• Retiros desde exchanges o faucets donde es el emisor quien decide el monto.
• Autenticación en sitios web usando la clave de un nodo Lightning.

LNURL es una familia de subprotocolos diseñados para cubrir estos huecos sin modificar la especificación de Lightning. No es parte del estándar BOLT; es una capa construida encima usando peticiones HTTP.

Cómo funciona LNURL

En esencia, LNURL es una URL HTTPS codificada en bech32 que apunta a un servidor controlado por el receptor. El flujo general es:

• El receptor genera una URL que apunta a su servidor.
• Esa URL se codifica en bech32 con el prefijo lnurl, resultando en algo como lnurl1dp68gurn8ghj7....
• El emisor escanea o copia ese LNURL en su billetera.
• La billetera decodifica la URL y hace una petición HTTP GET al servidor.
• El servidor responde con un JSON que describe qué acción ofrece (pagar, retirar, autenticar, etc.).
• La billetera muestra la acción al usuario y, si este confirma, hace una segunda petición para obtener una invoice BOLT 11 fresca.
• Finalmente, la billetera paga esa invoice por la red Lightning como cualquier otro pago.

LNURL no sustituye a las invoices: las envuelve. Toda operación LNURL termina generando una invoice BOLT 11 real que se liquida por Lightning.

Los subprotocolos principales

lnurl-pay

Permite al receptor publicar un identificador estático que otros pueden pagar en cualquier momento. El servidor responde con rangos de monto permitidos y metadata. La billetera emisora elige el monto, lo envía al servidor y recibe una invoice BOLT 11 para pagar. Es el subprotocolo más popular y la base de Lightning Address.

lnurl-withdraw

Invierte el flujo: en vez de que el usuario pague, el servidor le permite retirar fondos. La billetera del usuario genera una invoice por el monto deseado y se la envía al servidor, que la paga. Se usa en faucets, exchanges y casinos Lightning.

lnurl-auth

Permite autenticarse en un sitio web sin contraseñas. El sitio genera un desafío aleatorio embebido en un LNURL; la billetera del usuario firma ese desafío con una clave derivada determinísticamente de la seed, específica para el dominio. El sitio verifica la firma y concede acceso. Cada dominio usa una clave distinta, por lo que no hay correlación entre servicios.

lnurl-channel

Facilita que un nodo ofrezca abrir un canal con otro. El usuario escanea un LNURL y el servidor abre un canal Lightning hacia el nodo del usuario. Útil para onboarding de nuevos usuarios que necesitan liquidez entrante.

Lightning Address

Lightning Address es una capa de abstracción construida sobre lnurl-pay que hace que recibir pagos Lightning sea tan simple como dar un correo electrónico. Un Lightning Address tiene la forma [email protected] y funciona así:

• El emisor introduce [email protected] en su billetera.
• La billetera construye automáticamente la URL https://getalby.com/.well-known/lnurlp/alicia.
• Hace una petición HTTPS a esa URL, que responde con los parámetros estándar de lnurl-pay.
• Desde ahí, el flujo continúa como un lnurl-pay normal: la billetera solicita una invoice y la paga.

Lightning Address no es un nuevo protocolo: es una convención de nombres que mapea direcciones estilo email a endpoints lnurl-pay. Permite memorizar y compartir identificadores legibles, integrarlos en perfiles de redes sociales o en tarjetas de presentación.

Ventajas

• UX radicalmente mejor: un identificador estático, legible y reutilizable reemplaza invoices únicas y efímeras.
• Compatibilidad: funciona con cualquier billetera Lightning porque termina generando invoices BOLT 11 estándar.
• Casos de uso nuevos: donaciones en perfiles públicos, propinas, autenticación sin contraseña.
• Sin cambios en la red: LNURL vive fuera del protocolo Lightning, por lo que no requiere actualizaciones de nodos.

Limitaciones y compromisos de privacidad

LNURL y Lightning Address introducen un servidor intermediario, lo que conlleva sacrificios importantes:

• Dependencia del servidor: si el servidor LNURL está caído, no se puede recibir pagos aunque el nodo Lightning esté operativo.
• Metadatos expuestos: el servidor ve cada intento de pago, el monto y la IP del emisor. Puede correlacionar pagos y perfilar usuarios.
• Confianza en el dominio: con un Lightning Address alojado en un tercero, ese tercero controla el endpoint. Para máxima soberanía, hay que alojar el propio servidor LNURL.
• No es estándar BOLT: LNURL no forma parte de la especificación oficial de Lightning, y sus funciones se solapan con BOLT 12 offers, que pretende resolver los mismos problemas de forma nativa.

Comparación con invoices tradicionales

• Invoice BOLT 11: único uso, expira, sin servidor externo, mejor privacidad relativa, requiere comunicación emisor-receptor para cada pago.
• LNURL / Lightning Address: identificador estático y reutilizable, depende de un servidor HTTPS, el servidor ve todos los pagos, gran mejora de UX.
• BOLT 12 offers: identificador estático y reutilizable, sin servidor HTTP externo (usa onion messages), mejor privacidad, adopción todavía parcial.

En la práctica, Lightning Address domina hoy el caso de uso de "recibir pagos con identificador humano". A medida que BOLT 12 se generalice, es probable que coexistan durante años.

Nota: un Lightning Address no es una dirección Bitcoin on-chain. Solo puede recibir pagos a través de Lightning Network.