Qué pasó
El 13 de agosto de 2026 Bastien Teinturier, de ACINQ, publicó una divulgación en Delving Bitcoin sobre LND, la implementación de Lightning que mantiene Lightning Labs. En las versiones afectadas, "lnd olvidaba los canales que se cerraban de forma colaborativa inmediatamente después de su primera confirmación en cadena, sin esperar más bloques para protegerse de los reorgs. Si ocurría un reorg de 1 bloque, un atacante podía entonces publicar cualquier estado revocado de ese canal y lnd no publicaba transacciones de penalización, con una pérdida de fondos de hasta el monto completo del canal". Lo encontró en febrero de 2025 probando cierres cooperativos entre Eclair y LND, y el mensaje incluye los pasos en regtest para reproducirlo.
Qué cambia
Vale la pena seguir el mecanismo, porque es el mismo sobre el que se apoya cada canal Lightning. Ambos lados de un canal guardan transacciones de compromiso firmadas para cada saldo pasado, y cada vez que el saldo se mueve la anterior queda revocada. Revocada no significa borrada: la contraparte sigue teniendo una transacción válida que se paga a sí misma un saldo antiguo y mejor. Lo que impide que la difunda es que hay alguien mirando, y un estado revocado entrega el material de claves para quedarse con el canal entero como penalización.
Mirar es toda la defensa, así que un nodo que deja de mirar no tiene defensa. LND dejaba de hacerlo tras una confirmación en un cierre cooperativo. Una reorganización de la cadena de un solo bloque deshace esa confirmación, y el par que aceptó el cierre queda libre para difundir un estado revocado en la cadena reconstruida contra un nodo que ya no está mirando.
Ahora LND espera. Sus notas de versión registran que los cierres de canal requieren "entre 3 y 6 confirmaciones, escaladas linealmente con la capacidad del canal hasta el tamaño máximo de canal no wumbo (~0,168 BTC), y los canales wumbo requieren siempre 6 confirmaciones". El resumen que hace Teinturier de la lección es que las implementaciones "no deberían permitir que los operadores de nodos usen valores menores que 6".
Qué no cambia
No se sabe de nadie que haya perdido nada: la divulgación dice que "nadie resultó afectado hasta donde sabemos", y el ataque necesita un par que a la vez haya aceptado un cierre cooperativo y consiga que un reorg ocurra.
La información de versión es lo que hay que revisar antes de bajar la guardia. La
divulgación afirma que el arreglo llegó en la v0.20.0 en febrero de 2026. Las propias notas
de versión de LND sitúan el cambio,
pull request 10331, en la 0.21.0,
publicada el 5 de junio de 2026, y ninguna nota de versión 0.20.x lo menciona. El código
dice lo mismo: en la etiqueta v0.20.3-beta, publicada el 13 de agosto de 2026, el mismo
día que la divulgación,
el chain watcher
no contiene la palabra reorg ni una vez, mientras que
la versión 0.21.0 del mismo archivo
la contiene dieciséis veces.
CryptoSlate informó el 26 de agosto
de que un backport a la rama 0.20 fue revertido. La línea 0.20 sigue mantenida, así que un
nodo que lea "arreglado en 0.20.0" y se quede donde está no queda cubierto por esa frase.
Esperar confirmaciones reduce la exposición, no la elimina. Seis bloques son una convención sobre cuán profundo suele llegar un reorg, no una garantía sobre cuán profundo puede llegar, y el mismo razonamiento se aplica a cualquier política de confirmaciones en cualquier parte.
Contexto
Este es el segundo límite que LND pone este mes a lo que un par puede hacerle, después de un tope a cuántos datos del grafo de canales podía hacerle acumular un solo par. Ambos son la misma forma de arreglo: un par no es un adversario sobre el que se pueda razonar, así que el comportamiento del propio nodo tiene que sostenerse haga lo que haga el par.
La parte reutilizable no es sobre Lightning. Una divulgación vale lo que vale el número de versión que lleva dentro, y ese número es la única línea sobre la que un lector actúa sin comprobarla. Leer las notas de versión de la versión que realmente se ejecuta cuesta un minuto.