BOLT 12 es un protocolo de negociación de pagos Lightning mediante offer, invoice_request e invoice. La oferta es reutilizable, pero cada pago tiene condiciones propias y un resultado que verificar.
El receptor publica offer; el pagador envía invoice_request y recibe una invoice nueva. Solo entonces puede pagar. La oferta sirve a varias personas o pagos repetidos. Obtener una factura mediante fetchinvoice, por ejemplo, no la paga; publicar un QR no autoriza cargos permanentes. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice] [BOLT 12 — Project overview]
BOLT 12 almacena campos como TLV. Las ofertas de texto usan lno y las solicitudes lnr; el alfabeto se parece a Bech32, pero no tiene suma de comprobación final. La offer no lleva firma. Las firmas Schnorr BIP340 de solicitudes y facturas verifican la raíz Merkle de sus campos, no la identidad del comerciante. [BOLT 12 — Negotiation protocol]
La cartera compara los campos copiados de invoice_request con invoice, importe, cadena y firma. invoice_node_id debe coincidir con offer_issuer_id o el blinded_node_id final correspondiente. Una firma válida ajena no basta. La estructura Merkle permite pruebas selectivas de campos, no modificar libremente condiciones firmadas. [BOLT 12 — Negotiation protocol]
La invoice_amount de Bitcoin se expresa en msat; 1000 msat son un satoshi. offer_currency permite otra moneda según ISO 4217; USD usa centavos, por ejemplo. La cantidad de artículos y la conversión al emitir la factura afectan al precio. Si se indica invreq_amount, la factura debe coincidir; de lo contrario se verifica el rango autorizado. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
offer_paths transporta la solicitud; invoice_paths, el pago. La invoice actual debe contener blinded paths e invoice_blindedpay correspondiente, incluso si la ruta va directamente al receptor. El cegado limita la revelación de topología sin garantizar anonimato total, disponibilidad ni liquidez. Solicitar la factura no requiere un servidor de pagos HTTPS convencional. [BOLT 12 — Negotiation protocol] [BOLT 4 — Route blinding]
offer_absolute_expiry limita la oferta. invoice_created_at junto con invoice_relative_expiry limita la factura concreta; sin el segundo campo se aplican 7200 segundos. Una oferta reutilizable no da validez infinita a sus facturas. Los bits pares obligatorios desconocidos se rechazan; los impares desconocidos se ignoran. [BOLT 12 — Negotiation protocol]
En un reembolso, quien quiere enviar dinero puede publicar invoice_request sin offer. El receptor del dinero responde con su invoice; el pagador debe verificar al destinatario previsto, fuera del protocolo si hace falta. Es un pago nuevo, no la cancelación del anterior. Escanear una solicitud no demuestra un derecho ni aprueba el pago. [BOLT 12 — Negotiation protocol]
Conserve invoice, estado del pago y preimage correspondiente. El preimage demuestra la liquidación de la factura, pero no identifica por sí solo a la persona que pagó. Tras perder la respuesta, compruebe el estado antes de volver a pagar. Admitir ofertas no implica admitir toda extensión o pagos recurrentes automáticos; verifique recepción, envío y autorización de la aplicación por separado. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
Para obtener la imagen más completa, lee esta entrada junto con BOLT 11, Lightning Network, Lightning Routing, Privacidad en Bitcoin, Satoshi, LNURL. También enlazan con esta entrada BOLT 11, LNURL, Rusty Russell.