BOLT 11 es el estándar de factura Lightning firmada y codificada en Bech32. Incluye payment hash, información del receptor y condiciones de pago; es una solicitud, no una prueba de pago realizado.
Bech32 incorpora una suma de comprobación contra errores de transcripción; no cifra. Una firma ECDSA sobre secp256k1 protege el contenido y lo vincula a la clave del receptor, no a una persona verificada. A diferencia de las direcciones Bech32, BOLT 11 no tiene límite de 90 caracteres. El QR admite mayúsculas; mezclar mayúsculas y minúsculas es inválido. [BOLT 11 — Invoice protocol]
lnbc identifica mainnet, lntb testnet, lntbs signet y lnbcrt regtest. El importe se expresa en BTC con multiplicador m, u, n o p. Con p, la última cifra debe ser 0 para obtener msat enteros; 1000 msat equivalen a un satoshi. Si falta el importe, lo aporta el pagador; no significa pagar cero. [BOLT 11 — Invoice protocol]
El campo p contiene el payment hash: SHA256 del payment preimage. El campo s contiene payment_secret, exigido por el receptor en el tramo final del pago enrutado. El secret no es el preimage ni la semilla de la cartera. BOLT 11 actual exige ambos campos; leer el secret de la factura no prueba el pago. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
La factura incluye exactamente una alternativa: texto d o hash h de una descripción externa. Para h, la cartera debe comprobar el SHA256 de la descripción recibida; el hash solo no explica la compra. La firma vincula contenido y clave, pero no certifica una promesa comercial. El texto decodificado debe mostrarse de forma segura como datos. [BOLT 11 — Invoice protocol]
Timestamp más x determina la caducidad; sin x, el plazo predeterminado es de 3600 segundos. El campo c es min_final_cltv_expiry_delta del último HTLC en bloques, no otro plazo en segundos; si falta, se aplican al menos 18 bloques. La caducidad no revierte un pago completado. [BOLT 11 — Invoice protocol]
El campo 9 señala funciones obligatorias y opcionales. Un bit par desconocido exige rechazo; uno impar desconocido se ignora. Deben cumplirse las dependencias conocidas. Basic MPP solo se permite si se ofrece basic_mpp. Dividir el pago en partes no crea varias facturas independientes. [BOLT 11 — Invoice protocol] [BOLT 9 — Assigned feature flags]
El campo r añade routing hints para llegar al receptor; puede revelar claves de nodos, identificadores de canales y parámetros de comisiones. No acredita liquidez actual. El campo opcional f puede ofrecer una dirección on-chain, otro método de pago con comisiones y confirmaciones propias. La factura completa no es un contacto privado ni reutilizable indefinidamente. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
Tras enviar, distinga entre pendiente y completado. Conserve la factura y el preimage correspondiente como evidencia de liquidación, no solo una captura del QR. Si se pierde la respuesta, compruebe primero el estado en la cartera. Otra factura u otro método puede provocar otro pago; el formato por sí solo no protege universalmente contra repeticiones. [BOLT 4 — Onion routing] [Core Lightning — Payment result]
Para obtener la imagen más completa, lee esta entrada junto con Lightning Network, HTLC, BOLT 12, Nostr Wallet Connect, Satoshi. También enlazan con esta entrada Nostr Wallet Connect, BOLT 12, LNURL, Lightning Address.