Facturas: BOLT11 y BOLT12

Curiosidad

1. ¿Por qué una solicitud de pago que vence en una hora obliga a los comerciantes a realizar una regeneración constante?
2. ¿Cómo puede un código QR estático mantenerse válido durante años y al mismo tiempo generar facturas únicas y seguras para cada transacción?
3. ¿Qué campos de datos específicos permiten que una billetera verifique que una factura no ha sido manipulada antes de enviar fondos?

Explorar

1. Una factura BOLT11 es una cadena bech32 que comienza con 'lnbc' y que contiene todos los parámetros de pago necesarios. Codifica una cantidad opcional (en bitcoin, con una letra multiplicadora, hasta fracciones de un satoshi), un hash de pago específico derivado de una preimagen secreta, y una marca de tiempo de vencimiento por defecto de una hora. La clave pública del nodo beneficiario identifica el destino, mientras que las indicaciones de ruta opcionales guían al pagador si los canales directos no están disponibles. Toda la cadena es firmada por el beneficiario para garantizar su integridad.
2. Esta arquitectura hace que las facturas BOLT11 sean estrictamente de un solo uso. Una vez que el remitente paga el hash de pago asociado, la factura se considera liquidada y no puede canjearse nuevamente. Pagarla dos veces es inseguro: después del primer pago, la preimagen es conocida por todos los nodos de esa ruta, por lo que cualquiera de esos nodos que también forme parte de la ruta del segundo pago podría apropiársela. Esta restricción obliga al uso de códigos QR dinámicos en el comercio minorista, donde los comerciantes deben generar una nueva cadena para cada cliente, lo que complica el hardware de punto de venta.
3. Los desarrolladores de la comunidad resolvieron este problema mediante LNURL y direcciones Lightning, que dependen de servidores web externos. El usuario escanea una URI estática que apunta a un punto final del servidor; la billetera obtiene una factura BOLT11 nueva desde ese servidor antes de iniciar el pago. Esto separa la dirección pública de los datos específicos de la transacción, lo que permite que un único enlace sirva para pagos ilimitados, manteniendo al mismo tiempo la seguridad de facturas únicas y de uso único en segundo plano.
4. Las ofertas BOLT12, diseñadas por Rusty Russell y añadidas a la especificación en 2024, internalizan este flujo. Estos códigos de pago reutilizables comienzan con 'lno' y funcionan como identificadores estáticos para un nodo beneficiario. Al ser escaneados, la billetera del pagador envía un mensaje onion directamente a través de la red Lightning para obtener una factura nueva del creador de la oferta. Esto elimina la dependencia de servidores web externos, integrando la generación de solicitudes en el protocolo principal.
5. Las ofertas BOLT12 admiten funciones ausentes en BOLT11, incluyendo flujos en los cuales el comerciante paga al usuario, como reembolsos o retiros (se diseñaron pagos recurrentes, pero se eliminaron de la especificación final). Las ofertas también pueden utilizar rutas cegadas para esconder el nodo receptor dentro del grafo de canales, en lugar de publicar su clave pública. Este diseño reduce las fugas de privacidad en comparación con las facturas estándar que exponen directamente las indicaciones de enrutamiento o las direcciones de respaldo.
6. Los pagos espontáneos evitan por completo las facturas al utilizar los protocolos keysend o AMP (Atomic Multi-Path), en los cuales el remitente envía fondos a una clave de nodo conocida sin solicitud previa. Para verificarlo personalmente, pegue cualquier factura Lightning en un decodificador público BOLT11. Identifique el prefijo legible para humanos, la cantidad, el hash del pago, el tiempo de vencimiento y la firma del beneficiario. Compare esto con una cadena 'lno', que no contiene hash de pago, sino únicamente lo que el pagador necesita para solicitar una factura: el ID del nodo o las rutas cegadas hacia él.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• BOLT #11: Payment Requests (Lightning Network Specification)
• BOLT #12: Offers (Lightning Network Specification)
• A. M. Antonopoulos, O. Osuntokun & R. Pickhardt, Mastering the Lightning Network (2021)