Facturas Lightning (invoices) y BOLT 11

¿Qué es una factura Lightning?

Una factura Lightning (invoice) es un documento codificado que un receptor genera para solicitar un pago en Lightning Network. A diferencia de Bitcoin en la capa base, donde basta con conocer la dirección del destinatario para enviarle fondos, en Lightning el pago requiere que el receptor cree previamente una invoice que incluya un hash de pago único. Esa invoice contiene toda la información que la billetera (wallet) emisora necesita para encontrar una ruta y liquidar el pago correctamente.

Las invoices no son opcionales en Lightning tradicional: son el mecanismo criptográfico que garantiza que solo el receptor legítimo pueda reclamar el pago, gracias al uso de HTLCs (Hashed Time-Locked Contracts) a lo largo de la ruta.

El estándar BOLT 11

El formato de las facturas Lightning está definido por BOLT 11 (Basis of Lightning Technology nº 11), uno de los documentos de la especificación técnica que garantiza la interoperabilidad entre implementaciones como LND, Core Lightning, Eclair o LDK. BOLT 11 describe cómo codificar una invoice usando bech32, el mismo esquema de codificación utilizado por las direcciones nativas de SegWit en Bitcoin.

Una invoice BOLT 11 típica luce así:

lnbc2500u1p0wjf8rpp5qqq...sp5xyz...9qrsgq...

Aunque parezca una cadena aleatoria, cada sección cumple una función precisa.

Anatomía de una invoice BOLT 11

Una factura se descompone en los siguientes elementos:

• Prefijo HRP (Human Readable Part): indica la red. lnbc para mainnet, lntb para testnet, lnbcrt para regtest.
• Amount (monto): se coloca justo después del prefijo. Por ejemplo, 2500u significa 2500 microbitcoins (0,0025 BTC). Los sufijos son m (milli), u (micro), n (nano) y p (pico). Si no se especifica monto, la invoice es de monto abierto.
• Timestamp: marca Unix de cuándo se generó la invoice. Se usa junto con la expiración para determinar su validez.
• Payment hash: es el SHA-256 de un secreto (preimage) que solo el receptor conoce. Este hash es el núcleo criptográfico del HTLC: el receptor solo puede reclamar el pago revelando la preimage.
• Description (d) o description hash (h): texto libre con el concepto del pago, o el hash de ese texto si es demasiado largo.
• Payment secret: un valor adicional que protege contra ataques de probing y pagos duplicados.
• Expiration (x): segundos a partir del timestamp tras los cuales la invoice deja de ser válida. Por defecto, 3600 segundos (una hora).
• min_final_cltv_expiry (c): bloques mínimos que el último salto debe respetar antes de que el HTLC expire en la capa base.
• Route hints (r): pistas de enrutamiento opcionales que permiten al emisor encontrar rutas hacia nodos privados o no anunciados.
• Features (9): bitfield que indica qué características del protocolo soporta el receptor (MPP, payment secret, etc.).
• Firma: firma ECDSA del receptor sobre todo el contenido anterior, que permite al emisor verificar el nodo público destino.

Ejemplo desglosado

Tomemos una invoice simplificada:

lnbc2500u1pvjluezpp5qqqsyq...dq5xysxx...sp5zyg3zyg...9qrsgq...

• lnbc: mainnet de Bitcoin.
• 2500u: monto = 2.500 microbitcoins = 250.000 sats.
• 1: separador obligatorio entre HRP y payload.
• pvjluez: timestamp codificado en base32.
• pp5...: payment_hash (32 bytes).
• d...: description, por ejemplo "Café en la cafetería".
• sp5...: payment_secret.
• 9qrsgq...: features + firma del receptor.

Generación y pago

El flujo típico es el siguiente:

• El receptor genera aleatoriamente una preimage de 32 bytes y calcula su SHA-256 (payment hash).
• Construye la invoice añadiendo monto, descripción, expiración y route hints si su nodo es privado.
• Firma la invoice con la clave privada del nodo y la codifica en bech32.
• El emisor decodifica la invoice, verifica la firma, calcula una ruta hacia el nodo destino y lanza el pago mediante HTLCs encadenados.
• Cuando el HTLC llega al receptor, este revela la preimage para reclamarlo. La preimage se propaga de vuelta liquidando cada salto.

Facturas con y sin monto fijo

Una invoice puede incluir un monto específico o dejarlo abierto. Las invoices con monto fijo son el caso más común: el comercio define exactamente cuánto debe pagarse. Las invoices de monto abierto (zero-amount invoices) permiten al emisor decidir cuánto enviar, útiles para donaciones o propinas, pero no todas las billeteras las soportan.

Expiración

Toda invoice tiene un tiempo de validez. Una vez expirada, el receptor ya no garantiza tener la preimage disponible y el emisor no debe intentar pagarla. Esto es importante porque los precios en sats suelen calcularse al generar la invoice: si expira, probablemente el tipo de cambio haya cambiado y haya que solicitar una nueva.

Privacidad y route hints

Los nodos privados (típicamente billeteras móviles) no se anuncian en la red. Para que alguien pueda pagarles, la invoice incluye route hints: pistas que describen uno o varios saltos finales a través de canales privados hacia el receptor. Estas hints revelan parcialmente la topología privada del receptor. Además, el payment hash es único por invoice: reutilizar una invoice rompe la privacidad. Por eso las invoices son de un solo uso.

BOLT 12: offers, el futuro de las facturas

BOLT 11 tiene limitaciones importantes: las invoices son de un solo uso, expiran rápido, y no permiten pagos recurrentes sin interacción previa. BOLT 12 introduce el concepto de offer: una "meta-invoice" reutilizable que, mediante onion messages, solicita al receptor una invoice fresca en el momento del pago. Las offers permiten:

• Códigos QR estáticos que nunca expiran (para donaciones o menús de restaurante).
• Pagos recurrentes y suscripciones.
• Mayor privacidad, ya que no exponen directamente el nodo receptor.
• Respuestas (refunds) sin canal de comunicación externo.

BOLT 12 ya está implementado en Core Lightning y parcialmente en otras implementaciones, pero su adopción generalizada todavía está en curso.

Nota: al copiar una invoice Lightning, algunas billeteras aceptan tanto la cadena bech32 pura como el prefijo lightning: (por ejemplo, lightning:lnbc2500u1...). Ambos funcionan.