Facturas Lightning (invoices) y BOLT 11

¿Qué es una factura Lightning?

Una factura Lightning (invoice) es una petición de pago codificada que genera quien va a cobrar. En la capa base de Bitcoin basta con conocer una dirección para enviar fondos. En Lightning, lo normal es que antes de cada pago quien cobra cree una factura con un payment hash único. Esa factura lleva todo lo que la billetera (wallet) que paga necesita para buscar una ruta y completar el pago.

Con BOLT 11 la factura no es un trámite. Es la pieza que hace que el pago avance salto a salto con HTLCs (Hashed Time-Locked Contracts) y que solo se complete cuando quien cobra revela el secreto que corresponde a ese hash.

El estándar BOLT 11

El formato de las facturas está definido en BOLT 11 (Basis of Lightning Technology nº 11), uno de los documentos de la especificación que permiten que LND, Core Lightning, Eclair o LDK se entiendan entre sí. La factura se codifica en bech32, el mismo esquema de las direcciones SegWit v0 (bc1q…), aunque sin su límite de 90 caracteres.

Una factura BOLT 11 tiene este aspecto:

lnbc2500u1pvjluezsp5zyg3zyg3…pp5qqqsyqcyq5rqwzqf…dq5xysxxatsyp3k7enxv4jsxqzpu9qrsgq…

Parece una cadena aleatoria, pero cada trozo tiene su función.

Qué lleva dentro una factura

• Prefijo: indica la red. lnbc para mainnet, lntb para testnet, lntbs para signet y lnbcrt para regtest.
• Importe: va justo después del prefijo. 2500u son 2.500 microbitcoins, es decir, 0,0025 BTC. Los sufijos son m (mili), u (micro), n (nano) y p (pico). Si no hay importe, la factura queda abierta y quien paga decide cuánto.
• Fecha (timestamp): el momento en que se creó, en tiempo Unix. Con la caducidad, marca hasta cuándo vale.
• Payment hash (p): el SHA-256 de un secreto, la preimagen (preimage), que solo conoce quien cobra. Para recibir el dinero tiene que revelar esa preimagen.
• Descripción (d) o hash de la descripción (h): el concepto del pago en texto, o su hash cuando el texto pasa de 639 bytes.
• Payment secret (s): un valor que va en la factura y que los nodos intermedios no ven. Así no pueden sondear a quien cobra (probing), y sirve también para juntar las partes de un pago multiparte.
• Caducidad (x): segundos desde la fecha de creación durante los que la factura vale. Si no se indica, son 3.600 segundos, una hora.
• Margen final de bloques (min_final_cltv_expiry_delta, c): cuántos bloques de margen exige quien cobra en el HTLC que le llega. Si no se indica, 18.
• Pistas de ruta (route hints, r): opcionales. Ayudan a llegar a nodos privados, que no se anuncian en la red.
• Capacidades (features, 9): qué partes del protocolo admite quien cobra, como los pagos multiparte o el payment secret.
• Firma: firma ECDSA del nodo que cobra sobre todo lo anterior. De ella sale la clave pública de ese nodo. Si alguien cambia un solo carácter, sale otra clave, así que la firma ata la factura a un nodo concreto. Pero solo te protege si sabes qué nodo esperabas: una factura alterada o fabricada por otro también trae una firma que cuadra, con la clave de su nodo. Importa de dónde sacas la factura.

Un ejemplo de la especificación, trozo a trozo

BOLT 11 trae como ejemplo una factura para pagar un café:

lnbc2500u1pvjluezsp5zyg3zyg3…pp5qqqsyqcyq5rq…dq5xysxxatsyp3k7enxv4jsxqzpu9qrsgquk0rl77n…

• lnbc: mainnet de Bitcoin.
• 2500u: importe de 2.500 microbitcoins, que son 250.000 sats.
• 1: separador entre la parte legible (prefijo e importe) y los datos.
• pvjluez: la fecha de creación, codificada.
• sp5…: el payment secret (32 bytes).
• pp5…: el payment hash (32 bytes).
• dq5…: la descripción, «1 cup coffee».
• xqzpu: caduca a los 60 segundos.
• 9qrsgq: las capacidades que admite.
• El resto: la firma del nodo y, al final, la suma de control de bech32.

Puedes decodificar este y otros ejemplos oficiales en el decodificador de facturas.

Cómo se crea y cómo se paga

• Quien cobra genera al azar una preimagen de 32 bytes y calcula su SHA-256, el payment hash.
• Arma la factura con el importe, la descripción, la caducidad y, si su nodo es privado, las pistas de ruta.
• La firma con la clave de su nodo y la codifica en bech32.
• Quien paga decodifica la factura, saca de la firma la clave del nodo que cobra, busca una ruta hasta ese nodo y lanza el pago con HTLCs encadenados.
• Cuando el pago llega, quien cobra revela la preimagen para quedárselo. La preimagen vuelve por la ruta y cada salto liquida su parte.

Facturas con importe y sin importe

Lo normal es que la factura lleve importe: el comercio dice exactamente cuánto hay que pagar. También se puede dejar en blanco (zero-amount invoice), y entonces quien paga elige la cantidad. Sirve para donaciones o propinas, pero no todas las billeteras lo admiten.

Caducidad

Toda factura tiene un plazo. Cuando vence, el nodo que cobra rechaza el pago y la billetera que paga no debería intentarlo. Tiene sentido: el importe en sats suele calcularse con el precio del momento, y pasado un rato ese precio ya no es el mismo. Si caduca, se pide una nueva.

Privacidad y pistas de ruta

Las billeteras móviles suelen ser nodos privados, que no se anuncian en la red. Para que se les pueda pagar, la factura incluye pistas de ruta: uno o varios saltos finales por canales privados hasta quien cobra. Esas pistas dejan ver una parte de cómo está conectado.

Además, cada factura tiene su propio payment hash. Si se pagara dos veces, los nodos de la ruta ya conocerían la preimagen del primer pago y podrían quedarse el segundo sin reenviarlo. Reutilizarla también delata que los dos pagos van al mismo sitio. Por eso las facturas son de un solo uso.

BOLT 12: las ofertas

BOLT 11 tiene dos limitaciones claras: cada factura sirve para un pago y caduca pronto. BOLT 12 añade la oferta (offer): un código reutilizable con el que la billetera que paga pide, mediante onion messages, una factura nueva en el momento de pagar. Las ofertas permiten:

• Códigos QR fijos que no caducan, para donaciones o para la carta de un bar.
• Más privacidad, porque pueden ocultar el nodo que cobra.
• Reembolsos sin tener que pedir otra factura por otro canal.

Los pagos recurrentes estaban en los primeros borradores, pero a octubre de 2026 la especificación de BOLT 12 no los incluye.

BOLT 12 ya forma parte de la especificación. A octubre de 2026 lo implementan Core Lightning, Eclair y LDK; LND no lo trae de serie y necesita LNDK, un programa aparte. Lo admiten billeteras como Phoenix, pero muchas otras siguen usando solo BOLT 11.

Nota: muchas billeteras aceptan la factura tal cual o con el prefijo lightning: delante (lightning:lnbc2500u1…). Las dos formas valen.