Pedidos de Pago (BOLT 11)
El formato de la invoice, por dentro
-
Eric de Castro - Atualizado em
⚡ Lightning · Técnico
La invoice es el pedido de pago que la origen lee para saber cuánto, para quién y con qué payment_hash. El formato es el BOLT 11, y en el fondo es una cadena bech32 — la misma codificación de las direcciones segwit, pero sin límite de tamaño.
La estructura de la cadena
Una invoice lnbc… tiene dos partes, separadas por el último 1 (el separador bech32):
- HRP (human-readable part):
ln+ la red (bcmainnet,tbtestnet…) + el valor opcional (dígitos + multiplicadorm/u/n/p). Ej.:lnbc2500u= 2500 micro-bitcoins. - Parte de datos: un timestamp (cuándo fue creada) + los campos con tag + la firma.
Los campos con tag
Cada campo de la parte de datos tiene un tipo (1 carácter bech32) y un tamaño. Los principales:
- p — payment_hash (el candado; obligatorio)
- s — payment_secret (amarra las partes de un MPP)
- d — descripción (texto) o h — hash de la descripción
- x — expiración (segundos) · c — min_final_cltv_expiry
- n — node id del destinatario · 9 — features
- r — pistas de enrutamiento (para canales privados) · f — dirección on-chain de fallback
La firma prueba quién la emitió
Al final viene la firma (65 bytes: r, s y un byte de recuperación), hecha sobre el HRP + la parte de datos. El detalle elegante: con el byte de recuperación, el pagador puede recuperar la clave pública (el node id) de quien firmó — así que la invoice prueba quién la emitió, incluso sin el campo n.
Pega una invoice y ve todo decodificado — incluso el nodo recuperado de la firma:
Decodificador de Invoice (BOLT 11)
Decodificador de Invoice (BOLT 11)
La evolución: offers (BOLT 12)
La invoice BOLT 11 tiene dos inconvenientes: es de uso único (cada pago necesita una invoice nueva) y expira. Terrible para un botón de donación fijo o un QR impreso en un cartel.
El BOLT 12 lo resuelve con los offers: una dirección de pago reutilizable (la cadena empieza con lno1). Un mismo offer sirve para cualquier valor, cuantas veces quieras, y no expira.
Cómo un offer se convierte en un pago
A diferencia del BOLT 11 (donde la invoice ya es el documento final que pagas), el offer es solo una invitación. A la hora de pagar:
- La cartera del pagador lee el offer y envía una solicitud de invoice (
invoice_request) al destinatario — por la propia red Lightning, en un mensaje cifrado (onion), y no por un servidor web. - El destinatario responde con una invoice fresca (una invoice BOLT 12, con su propio
payment_hash), firmada al momento. - La cartera paga esa invoice normalmente.
Todo eso ocurre tras bastidores, en segundos, y usa caminos cegados (blinded paths) para ocultar el nodo del destinatario. Resultado: cada pago tiene una invoice única (sin reutilizar payment_hash) y quien recibe queda más privado.
Offer (BOLT 12) × Lightning Address
Los dos dan una "dirección reutilizable", pero por caminos bastante diferentes:
- Lightning Address (
nombre@dominio) usa LNURL sobre HTTP: la cartera hace una petición a un servidor web del dominio para buscar la invoice. Es simple y ampliamente compatible, pero depende de ese servidor (y del dominio) y es menos privado. - Offer BOLT 12 hace la misma negociación dentro de la propia red Lightning, sin servidor web ni dominio, y con más privacidad. A cambio, el soporte en las carteras todavía es menor.
Por eso nuestra página de donación ofrece los dos: una Lightning Address (funciona en casi cualquier cartera) y, para quien tenga una cartera compatible, un offer BOLT 12.
El BOLT 12 aún está en adopción: ya funciona en carteras/nodos como Phoenix, Core Lightning y versiones recientes de LND, pero no todas las carteras lo reconocen (Wallet of Satoshi, por ejemplo, todavía no). También hay extensiones en desarrollo, como offers con recurrencia (suscripciones).
A continuación, bajamos al nivel de los mensajes intercambiados entre los nodos: el protocolo Wire.