La respuesta corta
Una factura Lightning es una solicitud firmada de un pago concreto, con fecha límite. La
cadena que empieza con lnbc codifica unos pocos datos: cuánto, a quién, bajo qué condición
se puede cobrar el dinero, y hasta cuándo. El nodo de quien recibe la firma, así que quien
paga puede comprobar que no fue alterada en el camino.
No es una dirección. Se compromete a un solo pago y vence, y esas dos propiedades son el punto y no un inconveniente. Si los canales y el ruteo son territorio nuevo, qué es la red Lightning cubre la maquinaria que esta cadena pone en marcha.
Qué codifica la cadena
El formato es
BOLT 11. Se divide
en el primer 1 entre una parte legible por humanos y una parte de datos.
La parte legible es un prefijo y un monto opcional. lnbc es la red principal de
Bitcoin, lntb la de prueba. El monto, si está, es un número seguido de un multiplicador:
m por una milésima de bitcoin, u por una millonésima, n por una milmillonésima, p
por una billonésima. El monto es opcional por diseño, porque "las direcciones de donación a
menudo no tienen un monto asociado".
La parte de datos es una marca de tiempo de 35 bits, después una serie de campos etiquetados, y al final una firma. Los campos etiquetados que vale la pena conocer:
| Campo | Contiene |
|---|---|
p | El hash de pago de 256 bits. "Su preimagen constituye la prueba de pago." |
s | El secreto de pago, que "impide que los nodos que reenvían sondeen a quien recibe el pago". Se exige exactamente uno. |
d u h | Una descripción, o el SHA-256 de una demasiado larga para entrar. Exactamente uno de los dos. |
n | La clave pública de 33 bytes del nodo que cobra. Opcional. |
x | Vencimiento en segundos. "Por defecto son 3600 (una hora) si no se especifica." |
c | El delta mínimo de expiración CLTV del último salto. Por defecto, 18. |
f | Una dirección on-chain de reserva, si quien cobra ofrece una. |
r | Pistas de ruteo: un id de nodo, un id de canal, y las comisiones y el delta de ese canal. |
9 | Bits de funcionalidades. |
La firma son 520 bits: 64 bytes de R||S más un byte de identificador de recuperación.
Cubre todo lo demás, siendo "una firma ECDSA compacta y válida sobre secp256k1 del hash
SHA-256 de: la parte legible por humanos (como bytes UTF-8) concatenada con la parte de
datos (excluyendo la firma)". El identificador de recuperación es la razón por la que el
campo n es opcional: quien paga puede recuperar la clave pública de quien cobra a partir
de la propia firma, de modo que "la identidad del nodo que cobra queda implícita". Es la
misma criptografía de clave pública que autoriza un gasto
on-chain, haciendo otro trabajo.
Los campos r importan más de lo que parece. Un nodo cuyos canales no están anunciados no
figura en el mapa de nadie, así que la factura tiene que llevar las indicaciones: si no hay
un canal público asociado a la clave de quien cobra, quien escribe la factura "debe incluir
al menos un campo r". Por eso una factura de un nodo privado es visiblemente más larga.
Por qué vence
Una factura sin campo x sirve durante una hora, y ese valor por defecto hace un trabajo
real.
La factura fija un monto en un momento, apunta a canales que pueden cerrarse, y compromete al nodo que cobra a guardar un secreto concreto y a honrar un pago que lo invoque. La especificación empuja a los dos lados a detenerse: quien paga, "una vez pasada la marca de tiempo más el vencimiento", no debería intentar el pago, y quien cobra, pasado ese mismo punto, no debería aceptarlo.
Un vencimiento no es un candado. Es una instrucción que el software bien portado de los dos extremos obedece.
El hash de pago es el recibo
Quien recibe genera un número al azar, la preimagen, lo pasa por SHA-256 y pone el hash
en el campo p. El dinero recorre la ruta únicamente contra ese número. Cuando el nodo
final libera la preimagen, esta vuelve por el camino en mensajes update_fulfill_htlc,
liquidando cada salto a su paso
(BOLT 2).
Quien paga y conserva la preimagen conserva algo que solo quien recibe pudo haber producido,
emparejado con una factura que esa misma parte firmó. Ese par es lo más parecido a un recibo
que tiene Lightning, y BOLT 12 es preciso sobre su límite: la prueba "solo puede demostrar
que una factura fue pagada (mostrando la preimagen del payment_hash), no quién la pagó. El
comerciante puede afirmar que una factura fue pagada y, una vez revelada, cualquiera puede
afirmar que la pagó también"
(BOLT 12). Prueba que
el pago ocurrió. No prueba de quién fue.
Qué pasa al pagar una factura vencida
Por lo general nada, que es el buen resultado. El nodo final rechaza el pago entrante, las promesas condicionales se deshacen salto por salto, y el dinero vuelve al canal de quien envió. BOLT 4 obliga al nodo que cobra a rechazar un pago que no reconoce: "si el hash de pago es desconocido: debe hacer fallar el HTLC", y lo mismo para un secreto de pago que no coincide (BOLT 4).
El caso incómodo es un hash que el nodo todavía reconoce. Cuando una factura ya fue pagada, la especificación permite cualquiera de las dos respuestas: el nodo final "puede tratar el hash de pago como desconocido" o "puede aceptar el HTLC con éxito". Que un segundo pago sea rechazado o aceptado en silencio queda a criterio del software que cobra, que es exactamente la razón para no reutilizar una factura.
Las formas que aparecen en la práctica
Casi nadie pega una cadena BOLT 11 a mano. Hay tres cosas delante de ella, y solo una es una factura.
Facturas sin monto. El monto se omite de la parte legible, y una billetera que lee una así "debería indicarle a quien paga que el monto no está especificado". Sirve para donaciones y propinas. Pagar de más está acotado y no es libre: quien cobra debería hacer fallar un pago "de más del doble del monto esperado" (BOLT 4).
LNURL-pay. Una URL HTTPS codificada en bech32, no una factura
(LUD-01). La billetera la consulta y recibe
JSON: una URL de callback, un minSendable y un maxSendable en milisatoshis, y algo de
metadata. Después le pide al callback un monto concreto y recibe pr, que la especificación
describe como una "factura lightning serializada en bech32"
(LUD-06). O sea que LNURL es una manera de
obtener una BOLT 11 nueva cada vez, no un reemplazo de ella.
Lightning Addresses. La forma usuario@dominio, que es LNURL-pay con la construcción de
la URL oculta. Una billetera que ve [email protected] consulta
https://bitcoin.org/.well-known/lnurlp/satoshi, y la respuesta "debe ser la misma que en
LUD-06, paso 3, y el flujo es el mismo"
(LUD-16).
Las dos compran reutilización a cambio de un servidor web. Algo tiene que responder esa petición HTTPS, así que la dirección deja de funcionar cuando el servidor se cae, y el servidor aprende la dirección IP de quien paga y qué está por pagar. Una Lightning Address es un nombre de dominio en el que se está confiando para que entregue la factura correcta.
BIP 353 resuelve parte de
eso moviendo la búsqueda al DNS. Las instrucciones de pago viven en un registro TXT en
user.user._bitcoin-payment.domain, "deben estar firmadas con DNSSEC", y las billeteras que
muestran un nombre verificado deberían anteponerle el símbolo de bitcoin para distinguirlo de
una dirección de correo. El BIP dice sin rodeos que "pretende extender y subsumir el esquema
existente de 'Lightning Address'".
Las offers de BOLT 12, la sucesión reutilizable
BOLT 12 reemplaza la factura por una offer, una cadena que empieza con lno1. La offer
es la parte reutilizable. Un comercio la publica en una página o un código QR, cada persona
que paga pide su propia factura por la propia red Lightning con un mensaje invoice_request,
y el comercio responde con una factura nueva. No hay ningún servidor web en el medio.
La especificación abre enumerando lo que viene a corregir, y uno de los puntos es el tema de este texto: las facturas BOLT 11 "deben entregarse por usuario y son activamente peligrosas si se hacen dos intentos de pago para el mismo usuario".
El soporte es desparejo y conviene verificarlo antes de depender de él. Core Lightning trae
un comando offer que "crea una offer (o devuelve una existente), que es un precursor de la
creación de una o más facturas"
(Core Lightning, offer).
LND no implementa offers por sí mismo; quienes las quieren ejecutan
LNDK, un demonio aparte cuyo propio README describía al
proyecto como "todavía experimental" en agosto de 2026.
Lo que una factura no hace
No es una dirección. Una dirección on-chain es una condición de gasto que sigue funcionando. Una factura es una solicitud de un solo pago, y las dos no son intercambiables, aunque una billetera las muestre en la misma casilla.
Es de un solo uso. Una factura, un hash de pago, una preimagen. Reutilizarla deja el resultado a criterio del software que cobra, cosa que la especificación permite explícitamente en cualquiera de los dos sentidos, y BOLT 12 califica la práctica de peligrosa con esas mismas palabras.
Una Lightning Address no es una factura. Es un nombre que obtiene una por HTTPS. La distinción deja de importar justo hasta que el servidor se cae.
Adónde seguir
Qué ocurre entre los dos extremos de un pago, y cuánto cuesta mantener un canal abierto, está en qué es la red Lightning. Dónde viven las llaves mientras todo esto pasa está en cómo elegir una billetera.