BOLT 12

Imagina una cafetería que quiere dejar un solo código en el mostrador para aportaciones voluntarias. Pagar varias veces la misma factura BOLT 11 ordinaria causaría problemas. BOLT 12 publica en su lugar una offer. El monedero del cliente envía una invoice_request para pedir su propia factura y el destinatario responde con una invoice nueva. Solo entonces se paga. Un QR impreso puede servir a distintas personas sin que todas usen la misma factura. Obtenerla, por ejemplo mediante fetchinvoice, todavía no envía dinero. La oferta tampoco autoriza a la cafetería a cargar más pagos en el monedero ajeno. [1] [3] [4]

La oferta puede indicar un precio en bitcoin o en otra moneda. El campo offer_currency utiliza códigos ISO 4217; por ejemplo, un importe en USD se expresa en centavos. Al emitir la factura pueden intervenir la cantidad de unidades y la conversión de moneda. El invoice_amount final en bitcoin se expresa en millisatoshi, milésimas de satoshi: 1000 msat = 1 sat. Antes de pagar, el pagador necesita conocer ese importe y la comisión, no solo el precio del cartel. Si la solicitud fija una invreq_amount exacta, la factura debe coincidir. De lo contrario, el monedero comprueba el intervalo autorizado y debería pedir otra aprobación si queda fuera. Convertir una moneda no debe convertirse en un consentimiento invisible a cualquier precio. [1] [3]

El código impreso puede seguir en el mostrador, pero la oferta también puede caducar mediante offer_absolute_expiry. Cada factura tiene además su momento de creación invoice_created_at y su plazo invoice_relative_expiry. Si falta ese plazo, se aplican 7200 segundos, dos horas. Una factura antigua no equivale, por tanto, a un contacto válido indefinidamente. Los monederos también deben entender las funciones obligatorias anunciadas en los mensajes. Un bit par desconocido señala una función necesaria y provoca el rechazo; uno impar desconocido es opcional y puede ignorarse. Es una medida de compatibilidad segura, no un obstáculo que deba sortearse editando el código a mano. [1]

Después de pagar, conserva la factura y el resultado del monedero. Entre las pruebas de liquidación está el preimage, un valor secreto que se obtiene al completarse el pago. El monedero calcula su hash, un dato de comprobación, y lo compara con el hash de pago de la factura. Junto con la factura permite demostrar que se pagó, pero no identifica por sí solo a la persona que pagó. Si la aplicación se desconecta o pierde la respuesta, revisa el estado del pago anterior antes de repetir; una factura nueva puede dar lugar a otro pago. Examina con el mismo cuidado las promesas de pagos recurrentes. Admitir BOLT 12 no significa admitir todas las extensiones ni autorizar cargos automáticos. Comprueba por separado si el monedero recibe pagos mediante ofertas, paga ofertas ajenas y qué permisos diste a la aplicación conectada. [1] [3]

Pedir una factura y transferir fondos utilizan la red con fines distintos. offer_paths lleva el mensaje de solicitud, mientras invoice_paths ofrece rutas para el pago. BOLT 12 emplea blinded paths, rutas que ocultan parte de la información de conexión al destinatario. Revelar menos de la estructura de la red ayuda a la privacidad, pero no promete anonimato total. Una ruta oculta tampoco garantiza disponibilidad del receptor ni liquidez: fondos suficientes en los lados necesarios de los canales. Técnicamente, una invoice actual debe incluir esas rutas y sus parámetros invoice_blindedpay, incluso si conduce directamente al receptor. Solicitar la factura no exige un servidor de pagos HTTPS convencional. [1] [2]

Cuando el comerciante quiere devolver dinero, la negociación cambia de dirección. Quien pretende pagar puede publicar una invoice_request sin offer previa. El cliente, ahora destinatario del dinero, responde con su propia invoice para que el comerciante la pague. No se borra ni revoca el pago original: se realiza uno nuevo en sentido contrario. El comerciante debe comprobar que la factura pertenece al destinatario previsto, a veces mediante comunicación fuera del protocolo. Escanear la solicitud no demuestra el derecho a una devolución ni aprueba la transferencia. El proceso técnico facilita la comunicación, pero no decide a quién corresponde el dinero. [1]

BOLT 12 guarda datos como TLV: cada campo indica tipo, longitud y valor. Una oferta textual empieza por lno y una solicitud por lnr. El juego de caracteres se parece a Bech32, pero no incluye su suma de comprobación final. Eso no dice por sí solo quién debe cobrar. La offer no está firmada. Las firmas digitales BIP340 Schnorr permiten verificar la factura y la solicitud habitual que responde a una oferta. Una solicitud independiente publicada sin oferta, por ejemplo para un reembolso, no lleva firma. La firma se vincula a la raíz de una estructura de Merkle: un dato de comprobación calculado a partir del conjunto de campos correspondientes. Así se pueden demostrar campos concretos sin revelar siempre todos los detalles. No permite modificar condiciones firmadas ni demuestra la identidad legal del comerciante. [1]

El monedero debe establecer que recibió respuesta a su propia solicitud, no cualquier factura correctamente firmada. Compara los campos copiados de invoice_request con invoice, además de la red, el importe y la firma. La clave pública invoice_node_id debe corresponder a offer_issuer_id; si la oferta utiliza en su lugar la ruta oculta correspondiente sin ese identificador, se comprueba su blinded_node_id final. Es como verificar que la cuenta es la de tu mesa, no solo que lleva un sello auténtico. La estructura de Merkle permite pruebas selectivas, pero no elimina la obligación de comprobar todas las condiciones necesarias. Una factura ajena válida no se vuelve correcta solo porque su firma pase el control. [1]