BOLT 11

Anna compra un libro electrónico. En lugar de datos bancarios, la tienda muestra una factura Lightning que su monedero interpreta. Anna no necesita entender la cadena: antes de confirmar, comprueba el importe, el concepto y la comisión. Algunas facturas dejan el importe abierto, por ejemplo para una aportación voluntaria. Lo introduce quien paga; omitirlo no equivale a pagar cero. Para quien quiera profundizar: lnbc identifica la red principal; lntb, testnet; lntbs, signet; y lnbcrt, regtest, estos últimos entornos de prueba. El importe codificado se expresa en BTC con un posible multiplicador m, u, n o p, no directamente en satoshi. Con p debe terminar en 0 para representar millisatoshi enteros: 1000 msat = 1 sat. [1]

La descripción conecta la solicitud técnica con un motivo comprensible, como el libro de Anna. La factura contiene el texto en el campo d o su huella digital en h. Esta huella se calcula con SHA256; el monedero debe comprobar que la descripción recibida por separado produce el mismo resultado. Ese dato corto de comprobación calculado a partir del texto se llama hash. La huella sola no permite leer el pedido. Una firma válida vincula la descripción a la clave del destinatario, pero no garantiza que el vendedor entregue el libro. Quien desarrolla la aplicación tiene además otra responsabilidad: la descripción es texto ajeno que debe mostrarse de forma segura como datos, nunca ejecutarse como código. [1]

Anna deja el pedido abierto y vuelve más tarde. Si el monedero indica que la factura ha caducado, debe pedir una nueva. La caducidad se calcula a partir del momento de creación timestamp y la duración x. Sin x, el valor predeterminado es 3600 segundos, una hora. Caducar no revierte un pago ya completado. El campo c, técnicamente min_final_cltv_expiry_delta, establece algo distinto: un margen temporal para el último pago condicionado, o HTLC, de la ruta. Un HTLC exige presentar el secreto correcto a tiempo para liquidar el pago. El margen se mide en bloques, no en segundos de validez de la factura; sin c, el pagador usa al menos 18 bloques. No hay que confundir ambos plazos. [1]

Los pagos Lightning recorren canales de pago. En un canal, dos partes actualizan cómo se reparten los fondos sin registrar cada pago habitual en la blockchain principal de Bitcoin. Para que el pago llegue, hace falta una ruta utilizable y fondos suficientes en los lados adecuados de los canales: liquidez. El campo r puede aportar routing hints, pistas para el último tramo. Ayudan a encontrar al destinatario, pero no muestran su capacidad disponible en tiempo real. También pueden revelar claves públicas de nodos, identificadores de canales y parámetros de comisiones; no consideres privada la factura completa. El campo opcional f puede ofrecer una dirección Bitcoin convencional como alternativa. Pagarla utiliza la cadena principal, tiene sus propias comisiones y necesita confirmaciones. No es simplemente otro botón para enviar del mismo modo. [1] [2] [5]

Ni escanear un QR ni recibir una factura equivale a obtener un recibo. Después de enviar, consulta el resultado en el monedero: pendiente no significa completado. La liquidación también se acredita con el preimage correcto, un valor secreto cuyo hash debe coincidir con el hash de pago de la factura. Puedes conservar ambos como prueba del pago, no como garantía de entrega del producto. Si la aplicación se desconecta o pierde la respuesta, comprueba primero el estado del pago original. Pedir otra factura o pagar de inmediato la dirección alternativa puede provocar un segundo pago. Algunos monederos reconocen los reintentos, pero el formato no ofrece protección universal entre aplicaciones y vías de pago. [2] [4]

La cadena usa codificación Bech32. Su suma de comprobación ayuda a detectar errores de transcripción; no es cifrado ni oculta el contenido. La firma digital ECDSA sobre secp256k1 cumple otra función: verificar que los datos corresponden a la clave del destinatario y no se han modificado después. No verifica la identidad legal ni la honradez de quien controla esa clave. A diferencia de las direcciones Bitcoin Bech32, BOLT 11 puede superar los 90 caracteres. Las mayúsculas resultan útiles para los QR, pero una cadena válida no puede mezclar mayúsculas y minúsculas. Normalmente la persona escanea o copia y el monedero realiza estas comprobaciones. [1]

El payment hash es la huella digital de un valor secreto, el payment preimage, calculada con SHA256 y guardada en p. Al completarse el pago, el pagador obtiene el preimage y verifica que la huella coincide. El campo s contiene en cambio payment_secret. El pagador ya lo lee en la factura y lo entrega al destinatario en el último tramo del pago enrutado; ayuda a protegerlo frente a sondeos de los nodos intermediarios. Secret no es el preimage ni la semilla del monedero. Leerlo de un QR no demuestra un pago ni permite recuperar el monedero. BOLT 11 exige actualmente p y s. Sus nombres parecidos esconden funciones diferentes: identificar el pago, aportar un dato necesario y acreditar la liquidación. [1] [2]

Los monederos también deben saber si pueden realizar el pago solicitado. El campo 9 contiene indicadores de funciones. Un bit par desconocido señala una función obligatoria y exige rechazar el pago; uno impar desconocido es opcional y puede ignorarse. También deben cumplirse las dependencias conocidas entre funciones. Basic MPP, por ejemplo, divide un pago en partes que se reúnen en el destinatario. Solo se puede usar si la factura ofrece basic_mpp. Eso no crea varias facturas independientes ni justifica volver a pagar cada parte. Para un principiante, la conclusión práctica es sencilla: no se debe eludir un aviso de función incompatible editando la factura; hay que resolver primero la compatibilidad de los monederos. [1] [3]