Las aplicaciones que integran versiones antiguas del Lightning Development Kit (LDK) pueden quedar expuestas a la pérdida de Bitcoin si una contraparte del canal miente sobre el estado de una actualización después de reconectarse. El fallo ya ha sido corregido en las versiones 0.2.7 y 0.1.13, publicadas el 1 de octubre para las ramas 0.2 y 0.1, respectivamente.
LDK es una biblioteca utilizada para construir monederos y aplicaciones de pagos sobre la red Lightning de Bitcoin. La corrección afecta al código que los desarrolladores incorporan dentro de sus propios productos, por lo que no basta con que exista una versión segura de la biblioteca: los equipos deben actualizar y desplegar de nuevo las aplicaciones que la utilizan.
Una reconexión podía abrir la puerta al conflicto
El problema aparecía cuando una contraparte del canal confirmaba haber recibido una actualización y, tras volver a conectarse, afirmaba lo contrario. Antes de la corrección, esa declaración podía llevar a LDK a firmar una transacción de compromiso incompatible con el estado que la otra parte consideraba válido.
Las transacciones de compromiso reflejan el estado acordado de un canal de Lightning y permiten liquidarlo en la cadena de bloques de Bitcoin. En el escenario descrito en la propuesta de cambios PR 5057, la transacción recién firmada no quedaba registrada por el monitor del canal de LDK, el componente que realiza el seguimiento de las reclamaciones que podrían hacerse en cadena.
Ese desfase podía convertir un pago reenviado en una pérdida para la aplicación que actuaba como intermediaria. El atacante podía confirmar la transacción en la cadena de bloques y dejar que el pago llegara al siguiente destinatario. Después, cuando expirase el contrato asociado al pago entrante, podía recuperar esos fondos, aunque el nodo que había reenviado el pago conociera el secreto que normalmente permite reclamarlo.
El resultado sería que la aplicación intermediaria habría enviado Bitcoin al siguiente receptor sin recuperar la cantidad correspondiente del canal de entrada. El riesgo, por tanto, no se limita a un error de sincronización: en determinadas condiciones, la descoordinación podía traducirse en una pérdida económica directa.
Qué cambia en las versiones corregidas
La solución restringe la retransmisión de una actualización al periodo en el que la confirmación de la contraparte sigue pendiente. Además, si esa contraparte asegura que no recibió una actualización que ya había reconocido, LDK fuerza el cierre del canal.
La versión 0.2.7 incluye también una corrección distinta relacionada con LSPS2, un flujo en el que un proveedor de liquidez abre un canal como parte de la gestión de un pago. En ese caso, un pago interceptado podía presentar un importe falso. El servicio habría abierto el canal y reenviado más Bitcoin del que aportaba el pago entrante, cubriendo la diferencia con sus propios fondos. La modificación correspondiente figura en la PR 5042.
Esta segunda exposición afecta al flujo de servicios LSPS2. Las notas de la versión 0.1.13 mencionan la corrección común del problema de reconexión, pero no incluyen la solución relacionada con LSPS2.
La actualización debe llegar al software desplegado
La documentación de arquitectura de LDK señala que el kit se compila y se ejecuta dentro de las aplicaciones. Por eso, los desarrolladores deben incorporar el código corregido al software que ya han distribuido.
En las integraciones LSPS2 hay además una consideración adicional: los contratos de pago que una versión anterior dejó pendientes conservan importes que no fueron validados. Los equipos deben revisar también esos contratos al actualizar la biblioteca.
El fallo de reconexión es independiente de otros problemas corregidos en versiones anteriores de LDK, como los relacionados con las comisiones de los splices o la carga de estados guardados. Tampoco afecta a Core Lightning, que es una implementación diferente de Lightning. Bitcoin Optech describió estas correcciones en su boletín del 9 de octubre.
