LNURL

Las facturas Lightning expiran y solo pueden pagarse una vez, lo que las hace incómodas de imprimir o publicar. LNURL lo resuelve poniendo una solicitud HTTPS delante de la factura: su billetera le pide a un servidor la solicitud de pago en el momento en que usted quiere pagar. Las especificaciones están fuera de los BOLT y se numeran a partir de LUD-01.

Cómo funciona

LNURL convierte un enlace estático en una conversación en vivo entre una billetera y un servidor.

Todo el truco está en el propio enlace. En su forma original, LUD-01, una URL HTTPS se codifica en bech32 con el prefijo lnurl, lo que produce una cadena de caracteres que resiste ser impresa como código QR o escrita en una ventana de chat. La forma más reciente, LUD-17, prescinde de la codificación y usa prefijos de esquema simples como lnurlp: delante de una URL normal, lo que resulta más corto y más fácil de depurar. En cualquier caso, la billetera decodifica el enlace, hace una solicitud GET y recibe un JSON que le indica de qué tipo de interacción se trata.

El campo tag de ese JSON decide todo lo que sigue. LUD-06 define payRequest, el flujo de pago: el servidor devuelve una URL de callback junto con los campos minSendable y maxSendable, ambos en milisatoshis, y una cadena de caracteres de metadatos que la billetera muestra. Usted elige un monto, la billetera vuelve a llamar con él y el servidor devuelve una factura BOLT11 recién generada por exactamente esa suma. LUD-03 define withdrawRequest, que funciona en sentido contrario: el servidor ofrece dinero y la billetera aporta una factura para recibirlo. LUD-02 solicita un canal a un par. LUD-04 define auth, en el que la billetera firma un desafío con una clave derivada para cada dominio, que es como algunos sitios Lightning le permiten iniciar sesión sin contraseña.

La propiedad de seguridad que conviene entender es limitada. LNURL garantiza que la factura procede del dominio del enlace y que su monto coincide con lo que usted aprobó, porque la billetera comprueba la factura recibida antes de pagar. No garantiza nada sobre quién controla ese dominio. Escanear un código LNURL pegado encima de uno auténtico en un puesto de mercado paga al servidor del atacante, y el pago se completa exactamente como se diseñó.

Dónde aparece

La mayoría de la gente se encuentra con LNURL sin llegar a ver nunca la palabra.

Las páginas de propinas y donaciones usan LNURL-pay detrás de un código QR, y por eso el mismo código impreso sirve para cien clientes distintos con cien montos distintos. Los obsequios en conferencias de Bitcoin y las tarjetas de faucet usan LNURL-withdraw: usted escanea, su billetera genera discretamente una factura y los sats llegan sin ninguna factura visible. Algunas billeteras Lightning y servicios web usan LNURL-auth como todo su sistema de inicio de sesión.

El mayor despliegue es indirecto. Una dirección Lightning, la forma user@domain, se define en LUD-16 y se construye directamente sobre LNURL-pay: la dirección se traduce en una ruta HTTPS well-known y a partir de ahí el flujo es un LUD-06 ordinario. Si su billetera admite direcciones Lightning, ya habla LNURL.

La principal salvedad es la disponibilidad. Como hay un servidor web en medio, un código LNURL solo es tan fiable como ese servidor y su certificado TLS. Una factura BOLT11, una vez generada, puede pagarse con el servidor desconectado; un enlace LNURL, no.

LNURL frente a factura BOLT11

LNURL es una forma de obtener una solicitud de pago; una factura BOLT11 es la solicitud de pago. Esa única diferencia explica sus propiedades. Una factura es autónoma, está firmada por el nodo destinatario, es válida durante un tiempo determinado y se puede pagar una sola vez. Un enlace LNURL no contiene monto, ni hash de pago, ni firma, sigue siendo válido indefinidamente y sirve para cualquier número de pagadores porque cada uno desencadena una factura nueva. Imprima una factura y morirá antes de una hora. Imprima un código LNURL y seguirá funcionando hasta que el dominio deje de hacerlo.