LNURL reúne procedimientos con los que una cartera Lightning y un servicio web intercambian la información necesaria para una tarea. Lightning permite realizar pagos rápidos con bitcoin; su factura es una solicitud con los datos que necesita la cartera para pagar. A partir del enlace, la cartera averigua si debe preparar un pago, recibir fondos retirados de un servicio o confirmar un inicio de sesión. El enlace por sí solo no es una factura ni prueba de que haya llegado el dinero.
Imaginemos que Ana escanea un código para apoyar a un creador, otro para canjear un vale y un tercero para entrar en una web. Usa el teléfono de la misma manera, pero autoriza algo distinto cada vez. LNURL distingue estas tareas: payRequest sirve para pagar, withdrawRequest para retirar fondos y login para iniciar sesión. Los documentos LUD describen cada procedimiento. Son acuerdos opcionales entre aplicaciones, no cambios en las reglas de Bitcoin. Que una cartera admita uno no significa que admita todos los demás. [1] [7]
Con payRequest, el servicio devuelve una descripción y un intervalo de importes. Ana comprueba el dominio —la dirección web del servicio—, lee la descripción y elige su aportación. Tras aceptar las condiciones, la cartera solicita una factura Lightning BOLT 11 concreta y comprueba que su importe coincida con el elegido antes de pagarla. Utiliza una dirección callback, los límites minSendable y maxSendable y la descripción metadata; envía el importe como amount y recibe la factura en pr. Los importes se expresan en msat, milésimas de satoshi: 1000 msat = 1 sat. El mismo QR público puede servir a otras personas, pero escanearlo no confirma un pago. [3]
En withdrawRequest se invierte la dirección. Ana quiere retirar un saldo del servicio, no pagarle. Su cartera crea una factura de cobro para que el servicio la pague. Este facilita un identificador k1, una dirección callback y los límites minWithdrawable y maxWithdrawable en msat; después de la autorización, la cartera envía su factura en pr. La respuesta OK indica que el servicio aceptó la solicitud, no que Ana haya recibido el dinero. La cartera sigue esperando el pago entrante. El código de retirada puede funcionar como un vale al portador: no lo publiques como si fuera un contacto habitual para recibir pagos. [4]
En otra web, Ana elige LNURL-auth. La cartera muestra el dominio y la finalidad de la solicitud con el tag login. Con su autorización, firma un desafío de un solo uso, k1, con la clave privada específica del dominio, linkingPrivKey. Envía al servicio la firma y la clave pública correspondiente, linkingKey, con la que se comprueba la firma. No entrega la clave privada. El servicio puede reconocer al titular cuando vuelve, pero esa comprobación no revela por sí sola su identidad real. La cartera no envía al servicio su seed, el valor secreto inicial del que se derivan las claves, ni su Seed Phrase, las palabras de recuperación. Técnicamente utiliza una firma ECDSA sobre secp256k1. El campo action puede pedir registro, inicio de sesión, vinculación de una cuenta u otra autorización, de ahí que convenga leer la confirmación completa. Firmar este desafío no es en sí un pago con Bitcoin. [5]
La solicitud, la respuesta del servicio y el movimiento efectivo del dinero son pasos distintos. Si Ana pierde la conexión, primero comprueba el pago original en su cartera. Un nuevo intento con otra factura puede producir otro pago. El procedimiento opcional LUD-21 añade una dirección verify para consultar una factura concreta: settled true informa de su liquidación, mientras que settled false indica que aún no se ha liquidado. OK no basta. La respuesta puede incluir un preimage, el valor secreto original asociado al pago. La cartera calcula su hash, un dato de comprobación, y lo compara con el hash de pago de la factura correcta. No basta con recibir cualquier valor secreto: debe corresponder precisamente a ese pago. Consultar el resultado no garantiza que el servicio esté disponible ni que exista liquidez entrante, la capacidad de encaminar dinero a la cartera receptora. [6] [3] [4]
HTTPS protege la comunicación entre la cartera y el servicio, no frente al propio servicio. Este puede observar las solicitudes, sus horarios y los usos repetidos. Para iniciar sesión también importa el dominio completo: cambiar el subdominio puede generar otra linkingKey y hacer que la web reconozca a un usuario distinto. Pasarse a otra cartera tampoco garantiza recuperar el mismo acceso, porque las aplicaciones derivan las claves de formas distintas. Antes de un cambio importante, comprueba cómo recuperar esa cuenta concreta. LNURL no determina quién conserva las claves de los bitcoins; eso depende de la cartera y del servicio. [2] [5]
El procedimiento básico LUD-01 representa una URL HTTPS u onion en Bech32. Es una codificación, no un cifrado de la dirección ni una factura BOLT 11. La cartera lee el tag directamente en el enlace o envía una petición web GET para obtener datos y descubre la operación en una respuesta JSON. Este formato da nombres y estructura a los datos para que la aplicación pueda leerlos. Por tanto, la imagen QR no acredita la identidad del destinatario. Importan el contenido del enlace y el dominio, la acción y las condiciones que aparecen después. [2]
En el flujo de pago, metadata es una cadena de texto que contiene un array JSON. Debe incluir una descripción text/plain; los demás tipos son opcionales. La cartera debe mostrarla junto al dominio y al importe para que la persona sepa qué autoriza. LNURL básico interpreta el cuerpo JSON de la respuesta, no simplemente el código de estado HTTP. Que el servidor responda no implica que la solicitud haya funcionado: puede devolver ERROR. Del mismo modo, recibir una factura en pr no significa haberla pagado. Una aplicación no debería reducir todas estas situaciones a una única marca verde. [2] [3]
Para obtener la imagen más completa, lee esta entrada junto con BOLT 11, BOLT 12, Lightning Network, Lightning Address, Privacidad en Bitcoin, Satoshi. También enlazan con esta entrada BOLT 12, Lightning Address, Confirmo.