Facturas Lightning: cómo funcionan BOLT11 y BOLT12

Las facturas de Lightning hacen posibles los pagos en esta red. Cada vez que escaneas un código QR para pagar por Lightning, tu billetera obtiene una factura. El código puede contener la propia factura (BOLT11) o ser reutilizable, como una oferta BOLT12 o un LNURL que la billetera usa para solicitar una factura nueva. La factura contiene lo necesario para enrutar el pago, incluidos el destinatario, el importe, el hash de pago, el vencimiento y las pistas de enrutamiento. Si entiendes cómo funcionan las facturas y en qué se distinguen BOLT11 y BOLT12, verás con más claridad cómo circulan los pagos por la red y por qué evoluciona el protocolo.

Verás cómo se usan los dos formatos de factura, en qué se diferencian y qué cambia BOLT12 para los pagos Lightning.

¿Qué es una factura Lightning?

Una factura Lightning es una solicitud de pago. A una dirección de Bitcoin en cadena puedes enviar el importe que quieras. Una factura Lightning suele especificar cuánto pagar, adónde enviar el pago y hasta cuándo es válida la solicitud. El destinatario genera la factura y la comparte con el remitente. La billetera del remitente lee los datos codificados para preparar y encaminar el pago.

Se llama «factura» porque solicita un pago concreto. Una factura Lightning estándar deja de poder usarse en cuanto se paga o vence. Una dirección de Bitcoin en cadena puede recibir varios pagos sin un plazo definido.

BOLT11: el estándar actual

BOLT11 (especificación 11 de Basis of Lightning Technology) es el formato de factura más extendido desde los primeros años de la red. Si has usado la red Lightning, ya has usado facturas BOLT11, aunque solo las hayas visto como códigos QR.

Anatomía de una factura BOLT11

Una factura BOLT11 es una cadena larga de caracteres alfanuméricos. Normalmente empieza por lnbc (para la red principal de Bitcoin), seguido de los datos del pago codificados. Estos son sus campos:

Prefijo de red: lnbc (red principal), lntb (red de pruebas) o lnbcrt (regtest)
Importe: el importe del pago codificado en la cadena. Por ejemplo, lnbc500n equivale a 50 satoshis. Puede omitirse en facturas de importe libre.
Marca de tiempo: indica cuándo se creó la factura.
Hash de pago: un hash de 256 bits del que depende el pago. El destinatario conoce la preimagen, el secreto que produce ese hash. El remitente la desconoce. Así se garantiza que un pago con varios saltos se liquide por completo o se devuelva.
Secreto de pago: un segundo valor aleatorio, distinto de la preimagen. Solo lo conoce quien tiene la factura y el destinatario rechaza los pagos que carecen de él. Así los nodos de la ruta no pueden hacer pruebas para identificar al destinatario. Toda factura BOLT11 debe incluirlo.
Destino (ID del nodo del beneficiario): la clave pública del nodo Lightning del destinatario. Normalmente se omite como campo explícito y la billetera la recupera de la firma.
Descripción: una explicación legible del motivo del pago, como «Café en la tienda X».
Vencimiento: cuánto tiempo es válida la factura. El valor predeterminado es 1 hora y se puede cambiar.
Pistas de enrutamiento: rutas sugeridas para llegar al destino. Son especialmente útiles si el nodo del destinatario tiene pocas conexiones en el grafo público.
Firma: firma criptográfica del destinatario que demuestra que creó la factura.

La factura de ejemplo de la especificación BOLT 11, lnbc2500u1pvjluez…fna3rh, desglosada en sus componentes. lnbc es el prefijo de Lightning en la red principal de Bitcoin. 2500u es el importe, 0,0025 BTC o 250 000 sats. 1 es el separador y pvjluez es la marca de tiempo, el 1 de junio de 2017. Luego vienen los campos. Cada uno empieza con una letra que lo identifica, seguida de dos caracteres que indican su longitud. s es el secreto de pago. Es distinto de la preimagen y demuestra que quien paga tiene la factura. p es el hash de pago, el candado que lo protege. d es la descripción. Su valor es «1 cup coffee» (una taza de café). x es el vencimiento, 60 segundos o 1 hora si se omite. 9 indica las funciones que admite la billetera del destinatario. Al final están la firma, que prueba quién creó la factura y revela el ID de su nodo, y una suma de comprobación que detecta caracteres mal escritos. El importe se expresa en bitcoins seguido de una letra: m para mili, u para micro, n para nano y p para pico. Así, 10n equivale a 1 sat. — **Una factura BOLT11 es una sola cadena dividida en campos.** Este ejemplo de la especificación cobra 0,0025 BTC por un café. De sus 271 caracteres, 104 corresponden a la firma y 55 a cada uno de los campos del secreto y el hash de pago. Por eso hasta una factura sencilla es larga. En este ejemplo se omiten los campos opcionales, como las pistas de enrutamiento.

Cómo funciona un pago BOLT11

El destinatario genera un secreto aleatorio de 32 bytes, la preimagen.
El destinatario aplica una función hash a la preimagen para obtener el hash de pago y lo codifica en una factura BOLT11.
El destinatario comparte la factura con el remitente por código QR, texto, NFC u otro medio.
La billetera del remitente descodifica la factura, lee el destino y el importe y busca una ruta por la red.
El pago pasa de un nodo intermediario a otro. En cada salto, el nodo retiene fondos hasta recibir la preimagen mediante un contrato con bloqueo por hash y tiempo, o HTLC.
El destinatario revela la preimagen al último nodo de la ruta. El secreto recorre la ruta en sentido inverso, cada nodo resuelve su HTLC y el pago se liquida.

Un pago BOLT11 en tres pasos. 1. El destinatario guarda un secreto, la preimagen, e incluye solo su hash en la factura que te llega como código QR o texto. El hash es un candado que solo la preimagen puede abrir. 2. El pago avanza salto a salto desde ti hasta el destinatario, pasando por dos nodos. El hash bloquea el pago en cada salto hasta que se presenta la preimagen. Si vence el plazo, el pago vuelve atrás. 3. Para cobrar, el destinatario revela la preimagen. Esta recorre la ruta en sentido inverso, todos los candados se abren y se paga cada salto. Tras el pago, la factura queda usada y el siguiente pago requiere otra. — **El hash de pago es un candado y la preimagen, que solo conoce el destinatario, es la clave que lo abre.** En cada salto, un contrato con bloqueo por hash y tiempo (HTLC) retiene el pago hasta que vuelve la preimagen. Si el secreto nunca llega, el bloqueo temporal devuelve el pago. Los pagos BOLT12 usan el mismo mecanismo.

Limitaciones de BOLT11

BOLT11 ha sido útil para la red Lightning, aunque su diseño tiene varias limitaciones:

Un solo uso. Cada factura tiene un hash de pago único. Una vez pagada, no puede pagarse de nuevo. Un comercio que genera miles de facturas para ventas por internet necesita un sistema que cree una para cada cliente. Eso añade complejidad.
Pérdida de privacidad del destinatario. La factura incluye la clave pública del nodo del destinatario. Quien vea la factura sabrá qué nodo recibe el pago y podría vincularlo a una dirección IP o a una identidad real.
Tamaño. Las facturas BOLT11 llevan una firma criptográfica y pueden ser bastante largas, sobre todo si incluyen pistas de enrutamiento. Eso dificulta que quepan en códigos QR pequeños y que una cámara de poca calidad pueda leerlos.
Reutilización mediante protocolos adicionales. LNURL y otras soluciones permiten reutilizar un punto de pago mediante protocolos que se añaden a la especificación de Lightning.
El destinatario debe estar en línea. Para generar una factura, el destinatario tiene que estar conectado. Si el nodo de un comercio se desconecta temporalmente, no puede crear facturas ni recibir pagos.

BOLT12: la siguiente generación

BOLT12, también llamado «Offers», cambia la forma de iniciar un pago para superar las limitaciones de BOLT11. Rusty Russell, desarrollador de Core Lightning, propuso para BOLT12 este modelo de solicitud y respuesta en dos pasos. Permite usar códigos de pago reutilizables, protege la privacidad del destinatario y da más flexibilidad a los pagos.

Cómo funcionan las ofertas BOLT12

El destinatario crea una oferta, un código de pago reutilizable, en lugar de generar una factura de un solo uso. El proceso es el siguiente:

El destinatario crea una oferta BOLT12 y la publica, por ejemplo en su web, en sus redes sociales o en una tarjeta impresa. La cadena de la oferta empieza por lno.
El remitente escanea o pega la oferta.
La billetera del remitente envía una solicitud de factura al nodo del destinatario mediante un mensaje con enrutamiento cebolla.
El nodo del destinatario genera automáticamente una factura única y se la devuelve al remitente.
La billetera del remitente paga la factura mediante el mecanismo habitual de HTLC.

La oferta indica con qué nodo contactar para pedir una factura. Carece de hash de pago y el importe es opcional. Para cada pago se genera una factura única cuando se solicita.

Cómo funciona una oferta BOLT12. La oferta es una cadena que empieza por lno1 e indica cómo llegar al nodo del destinatario. Puede incluir una descripción y un importe. Carece de hash de pago y se publica una sola vez, en una web, un perfil o una tarjeta impresa. 1. La escaneas. 2. Tu billetera envía al nodo del destinatario una solicitud de factura por Lightning en un mensaje cebolla. 3. El nodo responde con una factura para ese pago, con su propio hash. Los pasos 2 y 3 añaden un viaje de ida y vuelta. 4. Pagas la factura bajo la condición de ese hash, igual que en BOLT11. Para el siguiente pago usas la misma oferta y vuelves al paso 2 para solicitar otra factura. — **Una oferta le dice a tu billetera dónde pedir una factura.** Tu billetera solicita una factura nueva por Lightning para cada pago. Así puedes usar la misma oferta tantas veces como quieras.

Principales mejoras de BOLT12

Característica	BOLT11	BOLT12
Reutilización	Un solo uso	Reutilizable (varios pagos con la misma oferta)
Privacidad del destinatario	La factura revela el ID del nodo	Las rutas cegadas ocultan la identidad del destinatario
Tamaño del código QR	Grande (factura firmada con todos los datos)	Pequeño si la oferta identifica el nodo del destinatario (a partir de 60 caracteres). Cada ruta cegada añade unos 250 caracteres o más, así que una oferta privada puede ser tan larga como una factura BOLT11.
Creación sin conexión	No (el destinatario debe estar en línea)	La oferta puede crearse sin conexión. El destinatario debe estar en línea cuando llega el pago
Pagos recurrentes	Sin soporte nativo	Ausentes en la especificación aprobada. Estaban en los primeros borradores y ahora hay una propuesta abierta (bolts PR #1240)
Prueba de pago	La preimagen demuestra el pago	La preimagen demuestra el pago. Desde julio de 2026, la especificación también define pruebas del pagador (prefijo `lnp`), con las que puede demostrar que pagó una factura concreta (bolts PR #1346, incorporada el 27 de julio de 2026)
Reembolsos	Sin mecanismo estándar	Protocolo de reembolso integrado

Rutas cegadas para ocultar al destinatario

Las rutas cegadas son una de las funciones más importantes de BOLT12. La oferta puede incluir una ruta cegada en vez del ID del nodo del destinatario. Los saltos intermedios van cifrados y cada nodo de la ruta solo conoce el siguiente paso. El remitente puede encaminar el pago sin saber qué nodo es el destinatario.

Dos rutas desde ti hasta un destinatario. Con una factura BOLT11, tu billetera ve todos los nodos hasta el destinatario. La factura revela el ID de su nodo, aquí 03e715…, tomado del ejemplo de la especificación. En una ruta cegada BOLT12, la billetera solo ve el trayecto hasta un nodo de introducción, un nodo público que elige el destinatario. Los saltos que vienen después solo muestran identificadores que parecen aleatorios. Uno de ellos es el destinatario y no puedes saber cuál. Puede añadir saltos ficticios al final para ocultar a qué distancia está. El pago llega porque cada nodo de la ruta cegada puede leer solo adónde debe enviarlo a continuación. — **Una ruta cegada te permite pagar a alguien sin saber cuál es su nodo.** El destinatario construye la ruta y cifra las instrucciones de cada salto. Después del nodo de introducción solo ves identificadores que parecen aleatorios. En BOLT11, cada factura identifica el nodo del destinatario.

La mejora de privacidad es importante. Cada factura BOLT11 revela la clave pública del nodo del destinatario, así que las empresas de análisis de cadenas y de vigilancia pueden trazar mapas de los nodos que reciben pagos. Las rutas cegadas rompen ese vínculo y hacen que los pagos Lightning sean más privados a nivel de protocolo.

Pagos recurrentes y suscripciones

Los pagos recurrentes quedaron fuera de la versión aprobada de BOLT 12. Figuraban en los primeros borradores de las ofertas y se retiraron de la versión incorporada a la especificación en septiembre de 2024 (bolts PR #798). La especificación incluye «Re-add recurrence» entre sus posibles ampliaciones. La propuesta para recuperarlos, bolts PR #1240, seguía abierta a fecha del 3 de noviembre de 2026.

Si la propuesta se incorpora y las billeteras la implementan, una oferta de suscripción especificaría un calendario, por ejemplo mensual, y la billetera del pagador podría enviar el pago en cada fecha. Eso haría innecesario el sistema de suscripciones que cada aplicación Lightning crea por su cuenta. Por ahora, las aplicaciones se encargan de gestionar cualquier suscripción que se pague por Lightning.

Adopción en 2026

La compatibilidad con BOLT12 varía según la implementación:

Core Lightning (CLN): compatibilidad completa con BOLT12. CLN fue la primera implementación importante con soporte nativo para ofertas.
Eclair (y Phoenix Wallet): admite BOLT12. Phoenix puede enviar y recibir pagos mediante ofertas BOLT12.
LND: LND 0.21 (junio de 2026) añadió el reenvío de mensajes cebolla y la búsqueda de rutas para esos mensajes, el transporte que necesita BOLT 12, aunque sigue sin admitir ofertas de forma nativa (notas de la versión 0.21, última versión v0.21.6, del 30 de octubre de 2026). Se están incorporando los formatos de mensajes BOLT 12 a la rama principal de LND para la próxima versión principal, que a fecha del 3 de noviembre de 2026 aún no se había publicado. Mientras tanto, LNDK (v0.3.0, septiembre de 2025) añade ofertas a LND como un proceso independiente.
LDK: admite BOLT12, por lo que las billeteras desarrolladas con Lightning Dev Kit tienen esta función a su alcance.
Pool de minería OCEAN: admite ofertas BOLT12 para pagar a los mineros. Estos pueden recibir pagos pequeños y periódicos en su billetera Lightning mediante una oferta reutilizable.

La adopción avanza, pero todavía no es universal. En 2026 la mayoría de los usuarios sigue utilizando principalmente facturas BOLT11. BOLT12 gana terreno a medida que las implementaciones maduran y las billeteras incorporan esta función en sus interfaces. Gracias a la retrocompatibilidad del protocolo Lightning, tu billetera puede admitir BOLT11 y BOLT12 a la vez.

LNURL: el protocolo puente

Entre BOLT11 y BOLT12, la comunidad desarrolló LNURL, un conjunto de protocolos que amplían BOLT11 sin cambiar la especificación principal. LNURL-pay ofrece enlaces de pago reutilizables. LNURL-withdraw permite solicitar el cobro de fondos. LNURL-auth permite iniciar sesión con Lightning. Las direcciones Lightning, con el formato usuario@dominio.com, se basan en LNURL-pay.

LNURL resolvió muchas limitaciones de BOLT11 antes de que BOLT12 estuviera listo. LNURL requiere un servidor web que intermedie en la solicitud. Esto crea un punto central de fallo y puede comprometer la privacidad. BOLT12 ofrece funciones parecidas en el propio protocolo, sin infraestructura externa.

Dos formas de obtener una factura nueva a partir de un código de pago reutilizable. Si usas una dirección Lightning como nombre@dominio.com, basada en LNURL, tu billetera consulta por HTTPS un servidor web del dominio del destinatario. El nodo del destinatario crea la factura y el servidor devuelve una factura BOLT11. El servidor actúa como intermediario, debe estar en línea y ve todas las solicitudes. Si usas una oferta BOLT12, lno1…, tu billetera consulta por Lightning al nodo del destinatario con un mensaje cebolla. El propio nodo devuelve una factura BOLT12 sin pasar por un servidor web. En los dos casos, luego pagas la factura por Lightning. — **Una dirección Lightning y una oferta BOLT12 te dan una factura nueva para cada pago.** Con la dirección responde un servidor web. Con la oferta responde el nodo del destinatario.

A largo plazo se espera que BOLT12 cubra cada vez más usos de LNURL. LNURL seguirá disponible para mantener la retrocompatibilidad y para algunas integraciones web.

Qué cambia al usar Lightning

¿Cómo se traduce todo esto en el uso cotidiano de Lightning?

Para pagar facturas: tu billetera se encarga de los detalles técnicos. Tanto si escaneas una factura BOLT11 como si escaneas una oferta BOLT12, el proceso es parecido: escanear, confirmar el importe y pagar. Billeteras actuales como Phoenix manejan ambos formatos sin que tengas que elegir.
Para recibir pagos: con una oferta BOLT12 puedes publicar un único código de pago en tu web o en tu perfil. Cualquiera puede pagarte varias veces con ese código sin que tengas que generar una factura para cada transacción.
Para proteger tu privacidad: si te importa la privacidad, elige billeteras y servicios que admitan BOLT12 con rutas cegadas. Así evitas que cada solicitud de pago revele la identidad de tu nodo.
Para las suscripciones: los pagos recurrentes siguen siendo una propuesta abierta para BOLT 12. Si se incorporan y las billeteras los admiten, podrías suscribirte a contenidos o servicios de pago con Lightning sin infraestructura especial.

Preguntas frecuentes

¿Puedo usar BOLT11 y BOLT12 a la vez?

Sí. Las billeteras compatibles con ambos formatos pueden enviar y recibir pagos con cualquiera de ellos. BOLT11 sigue siendo la opción para operar con billeteras y servicios que aún no han adoptado BOLT12. Ambos formatos conviven en la misma red Lightning.

¿Tengo que hacer algo para pasar a BOLT12?

Puedes seguir usando tu billetera como hasta ahora. Cuando se actualice para admitir BOLT12, podrás crear y pagar ofertas además de usar facturas tradicionales. Consulta las notas de versión de tu billetera para conocer su compatibilidad con BOLT12.

¿Los pagos BOLT12 son más rápidos que los BOLT11?

El pago circula a la misma velocidad, porque ambos formatos usan el mismo enrutamiento por HTLC. BOLT12 añade una ida y vuelta antes de enviar el pago. Tu billetera pide una factura y el nodo del destinatario se la manda. La petición y la factura viajan por Lightning como pequeños mensajes cebolla.

¿Qué es una dirección Lightning?

Una dirección Lightning se parece a una dirección de correo electrónico (usuario@dominio.com) y se basa en LNURL-pay. Si alguien te paga con tu dirección Lightning, su billetera solicita una factura BOLT11 a un servidor web de tu dominio. Es cómodo, aunque requiere un servidor web y carece de las ventajas de privacidad de las rutas cegadas de BOLT12.

¿Dejará de funcionar BOLT11?

No. BOLT11 está muy integrado en el ecosistema Lightning y seguirá funcionando en el futuro previsible. BOLT12 se suma a las funciones existentes. La especificación Lightning conserva la retrocompatibilidad, así que las funciones nuevas conviven con las anteriores.

Parte de nuestro curso gratuito de Bitcoin: profundiza en este tema con Canales y enrutamiento en Lightning: cómo encuentran su ruta los pagos, del curso Red Lightning y nodos de Bitcoin.