Un error en versiones antiguas de Lightning Terminal podía mostrar como pagada una factura de Bitcoin Lightning después de que el pago se cancelara y los fondos volvieran al remitente. Lightning Labs afirma que corrigió los defectos en 2025, aunque no informó si hubo pérdidas comerciales.
***

• El problema podía llevar a un comerciante a entregar bienes o crédito sin recibir el pago, aunque los fondos del remitente no estaban en riesgo.
• La discrepancia surgía cuando un HTLC cancelado no actualizaba correctamente el estado de la factura en la base de datos de lnd.
• Las correcciones llegaron en taproot-assets v0.5.1 y lnd v0.19.0-beta; Lightning Terminal v0.15.0-alpha incluye ambas.

⚡️🚨 Un fallo podía marcar como pagadas facturas Lightning canceladas

Los fondos volvían al remitente, pero comercios podían entregar bienes o crédito sin cobrar.

Lightning Labs corrigió los defectos en 2025. El aviso no cuantificó pérdidas comerciales. pic.twitter.com/Bxv9VDmaSq

— Diario฿itcoin (@DiarioBitcoin) September 25, 2026

Lightning Labs reveló un fallo que podía dar por pagadas facturas canceladas

Una factura podía mostrar un pago que no llegó

Lightning Labs divulgó el 21 de septiembre de 2026 un fallo en versiones antiguas de Lightning Terminal que podía hacer aparecer como liquidada una factura de Bitcoin Lightning después de que el pago se cancelara. En el escenario descrito, los fondos regresaban al remitente, pero el sistema del receptor mantenía un estado que indicaba que la operación había concluido. Un comerciante que confiara en esa señal podía entregar productos o conceder crédito sin haber recibido el dinero.

La compañía calificó la vulnerabilidad como de severidad alta por el riesgo que representaba para operadores y servicios de pago que usan el estado de una factura para decidir si liberan bienes o valor. Sin embargo, el aviso no cuantificó pérdidas reales ni indicó cuántos comercios pudieron verse afectados. Lightning Labs también señaló que el dinero del remitente no estaba en riesgo, una distinción relevante frente a fallos que permiten desviar o sustraer fondos.

El defecto no correspondía a un problema de la cadena base de Bitcoin, sino a una discrepancia entre el resultado del pago Lightning y la información que conservaba el software receptor. La red podía cancelar el pago y devolver los fondos, mientras que el nodo mantenía registrada la factura como liquidada. En la práctica, el peligro aparecía si una persona o un sistema automatizado tomaba esa marca como confirmación suficiente para completar una venta.

El aviso no presenta el fallo como una vulnerabilidad que permita al comprador quedarse con fondos ajenos; describe, en cambio, una señal contable incorrecta que podía inducir al comerciante a asumir que ya había cobrado. Esa diferencia delimita el impacto reportado: el remitente recuperaba su dinero, pero el vendedor podía desprenderse de bienes o conceder crédito sin recibir el pago. La ausencia de datos sobre incidentes impide saber si el riesgo se tradujo en pérdidas verificadas.

La interacción entre tapd y lnd originaba la discrepancia

Lightning Terminal reúne tapd, el software para Taproot Assets, y el nodo Lightning lnd. En la configuración afectada, tapd activaba un interceptor de facturas y trataba como pagos de activos cualquier HTLC que incluyera registros de cable personalizados. El disparador no exigía que el comerciante tuviera canales de activos abiertos, de acuerdo con la explicación de Lightning Labs, por lo que esa condición no bastaba para descartar la exposición.

Un HTLC, o contrato con bloqueo de tiempo mediante hash, sirve para encaminar fondos en Lightning bajo condiciones criptográficas y temporales. En el caso descrito, el pago se cancelaba en la red y volvía al remitente, pero la factura no reflejaba ese desenlace en el registro del nodo receptor. El punto crítico, por tanto, no era que el contrato transfiriera los fondos de forma permanente, sino que los componentes del software no coincidían al informar el resultado.

El aviso vincula el detonante con algunas implementaciones del lado del remitente que añadían un registro experimental de respaldo, denominado endorsement, incluso a pagos ordinarios de BTC. Al encontrar registros de cable personalizados, la regla estricta de reenvío de tapd instruía a lnd a cancelar el conjunto de HTLC. Esa secuencia podía interrumpir el pago aunque se tratara de una transferencia de Bitcoin y no de un pago de activos.

El segundo defecto estaba en lnd: cuando un interceptor cancelaba el conjunto de HTLC, las versiones afectadas podían cancelar el pago en el cable y, aun así, marcar la factura como liquidada en su base de datos. Lightning Labs indicó que otra implementación que usara la interfaz HtlcModifier de lnd para cancelar ese conjunto podía producir la misma discrepancia. Así, el comportamiento no se limitaba al interceptor de tapd, aunque el aviso también identifica esa ruta como un detonante observado.

Las correcciones estaban disponibles desde 2025

Lightning Labs enumeró como afectadas las versiones anteriores de Lightning Terminal, taproot-assets hasta la v0.5.0 y lnd desde la 0.18.4-beta hasta la 0.18.5-beta. La empresa indicó que Lightning Terminal v0.15.0-alpha incorpora correcciones para ambos defectos. Esa versión reúne, por tanto, la solución al manejo del disparador asociado con tapd y al error de contabilidad de facturas en lnd.

La corrección del detonante de tapd llegó primero: taproot-assets v0.5.1 la incorporó el 12 de febrero de 2025. Lightning Terminal v0.14.1-alpha ya incluía ese ajuste, pero su versión integrada de lnd todavía conservaba el defecto subyacente que afectaba el estado de las facturas. Por eso, aplicar solo la primera corrección no eliminaba la discrepancia completa descrita en el aviso.

El arreglo para el registro de facturas llegó después con lnd v0.19.0-beta, publicado con la corrección el 22 de mayo de 2025. La divulgación de septiembre de 2026 se refiere, por tanto, a fallos cuyas correcciones pertinentes se habían publicado el año anterior. La información disponible no detalla por qué se hizo pública en esa fecha ni especifica una fecha límite para que los operadores instalaran versiones corregidas.

Para operadores que no puedan actualizar y no tengan canales de activos, Lightning Labs identificó --taproot-assets-mode=disable como una forma de evitar el detonante observado en tapd. La medida se presenta como alternativa para esa configuración concreta, no como reemplazo general de las correcciones disponibles. La recomendación práctica que se desprende del aviso es verificar tanto la versión de Lightning Terminal como las versiones de sus componentes integrados, porque el ajuste de tapd por sí solo no corregía el defecto de lnd.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín