LNURL y Lightning Address

El problema que LNURL resuelve

Las facturas (invoices) BOLT 11 funcionan, pero son incómodas. Para cada pago, quien cobra tiene que generar una factura nueva, hacérsela llegar a quien paga y esperar a que la pague antes de que caduque. Eso deja fuera muchos usos normales:

• Donaciones públicas, en las que quien cobra no habla con quien paga.
• Una dirección fija para recibir, como un correo, que se pueda poner en un perfil o en una tarjeta.
• Retiradas desde un exchange o un faucet escaneando un código, sin copiar facturas a mano.
• Entrar en una web con una clave de tu billetera, sin contraseña.

LNURL es una familia de pequeños protocolos para cubrir esos huecos sin tocar la especificación de Lightning. No forma parte de los BOLT: es una capa que va por encima y funciona con peticiones HTTP.

Cómo funciona LNURL

Un LNURL es, en el fondo, una dirección HTTPS codificada en bech32 que apunta al servidor de un servicio. Este es el recorrido de lnurl-pay, el más común:

• Quien cobra crea una URL que apunta a su servidor.
• Esa URL se codifica en bech32 con el prefijo lnurl y queda algo como lnurl1dp68gurn8ghj7….
• Quien paga lo escanea o lo pega en su billetera (wallet).
• La billetera recupera la URL y le hace una petición al servidor.
• El servidor contesta con un JSON que dice qué ofrece; aquí, recibir un pago.
• La billetera se lo enseña al usuario y, si este acepta, hace una segunda petición para obtener una factura BOLT 11 recién creada.
• Por último, la billetera paga esa factura por Lightning como cualquier otro pago.

Las demás variantes cambian el final: en una retirada la billetera manda una factura en vez de pagarla, y en lnurl-auth firma un reto. LNURL no sustituye a las facturas, las envuelve. Todo cobro con LNURL acaba en una factura BOLT 11 normal que se paga por Lightning.

Los protocolos principales

lnurl-pay

Quien cobra publica un identificador fijo que cualquiera puede pagar cuando quiera. El servidor responde con el importe mínimo y máximo que acepta y una descripción. La billetera que paga elige el importe, se lo manda al servidor y recibe una factura BOLT 11 por esa cantidad. Antes de pagar, la billetera comprueba que la factura es por el importe que pidió. Es el más usado y la base de Lightning Address.

lnurl-withdraw

Va al revés: el servidor es quien paga. La billetera del usuario genera una factura por el importe que quiere retirar, se la manda al servidor y este la paga. Lo usan faucets y exchanges.

lnurl-auth

Sirve para entrar en una web sin contraseña. La web genera un reto aleatorio dentro de un LNURL. La billetera lo firma con una clave distinta para cada dominio, derivada de la seed (o, en billeteras montadas sobre un nodo, de una firma de ese nodo). La web comprueba la firma y te deja entrar. Como cada dominio ve una clave diferente, no pueden relacionar tus cuentas entre sí.

lnurl-channel

Sirve para que un servicio abra un canal hacia tu nodo. Escaneas el LNURL y el servidor abre el canal. Es una forma de conseguir liquidez entrante al empezar.

Lightning Address

Lightning Address se apoya en lnurl-pay para que cobrar en Lightning sea tan sencillo como dar un correo. Tiene la forma [email protected] y funciona así:

• Quien paga escribe [email protected] en su billetera.
• La billetera construye la URL https://example.com/.well-known/lnurlp/alicia.
• Le hace una petición HTTPS y recibe los datos de lnurl-pay.
• A partir de ahí es un lnurl-pay normal: la billetera pide una factura y la paga.

Lightning Address no es un protocolo nuevo. Es una forma de nombrar las cosas: convierte una dirección con aspecto de correo en la URL de un servidor lnurl-pay. Se recuerda, se comparte y se puede poner en un perfil o en una tarjeta de visita.

Ventajas

• Más fácil de usar: un identificador fijo y legible, sin pasar a mano una factura nueva para cada pago.
• Compatibilidad: al final se paga una factura BOLT 11 normal, aunque la billetera que paga tiene que entender LNURL o Lightning Address para pedirla.
• Usos nuevos: donaciones en perfiles públicos, propinas, entrar en webs sin contraseña.
• Sin cambios en la red: LNURL va por fuera del protocolo Lightning, así que los nodos no tienen que actualizarse.

Lo que se paga a cambio

LNURL y Lightning Address meten un servidor en medio, y eso tiene un coste:

• Dependes del servidor: si se cae, no puedes cobrar aunque tu nodo Lightning funcione.
• Ve tus datos: el servidor ve cada intento de pago, el importe y la IP desde la que pregunta la billetera que paga. Puede relacionar pagos y hacer perfiles.
• Confías en el dominio: si tu Lightning Address está en el dominio de otro, ese otro controla las respuestas. Puede devolver facturas de su propio nodo y quedarse los pagos. Si quieres control total, tienes que montar tu propio servidor LNURL.
• No es un BOLT: LNURL no está en la especificación oficial de Lightning, y BOLT 12 resuelve buena parte de lo mismo dentro del protocolo.

Frente a las facturas de siempre

• Factura BOLT 11: un solo uso, caduca, no necesita servidor aparte, deja ver menos datos y obliga a pasar una factura nueva para cada pago.
• LNURL / Lightning Address: identificador fijo y reutilizable, depende de un servidor HTTPS que ve todos los pagos, y es mucho más cómodo.
• Ofertas BOLT 12: código fijo y reutilizable, pero largo (lno1…); no necesita servidor HTTP porque usa onion messages, y da más privacidad. Para tener un nombre legible se combina con BIP 353 (₿usuario@dominio), que usa DNS en vez de un servidor HTTP. Todavía no lo admiten todas las billeteras.

Nota: una Lightning Address no es una dirección Bitcoin on-chain. Solo recibe pagos por Lightning Network.