ACINQ publicó Eclair 0.14.6 el 27 de octubre para corregir un riesgo por el que un nodo malicioso podía aprovechar transacciones de financiación de canales aún no confirmadas. La versión exige por defecto que las entradas utilizadas en operaciones de splice estén confirmadas y modifica los procedimientos de liquidación y recuperación de fondos cuando un canal debe cerrarse. ACINQ recomendó actualizar los nodos, aunque no ha informado de que estas vulnerabilidades se hayan explotado en la práctica.
Cómo podían quedar expuestos los pagos pendientes
Lightning Network permite transferir bitcoins mediante canales de pago, sin registrar cada operación individual en la cadena de bloques de Bitcoin. También es posible añadir o retirar liquidez de un canal existente mediante el «splicing», que depende de transacciones en cadena.
El riesgo aparece cuando una operación de splice acepta entradas de financiación aportadas por la contraparte antes de que la red Bitcoin las haya confirmado. Un nodo malicioso podría gastar dos veces la transacción correspondiente después de firmar el splice. Si eso invalida el acuerdo de financiación original, también puede afectar a la liquidación del canal.
Si el canal se cierra entonces en la cadena, podrían quedar expuestos pagos pendientes protegidos por contratos hash time-locked (HTLC), cuya liquidación depende de la transacción de financiación invalidada. ACINQ describió el problema como un posible riesgo de seguridad, pero no comunicó ningún robo de fondos confirmado.
Eclair exige entradas confirmadas para los splice
Eclair 0.14.6 incorpora un ajuste de seguridad que exige confirmar las entradas de financiación de la contraparte antes de utilizarlas en un splice. También impide construir nuevas operaciones de splice sobre cambios de financiación que todavía no se hayan confirmado, lo que limita la acumulación de estados de financiación pendientes de liquidación.
ACINQ aclaró que este requisito es independiente de las protecciones existentes de financiación dual de Eclair, que ahora se aplican específicamente a la creación de canales. Las operaciones de splice quedan cubiertas por la nueva comprobación de confirmación. Para las contrapartes no confiables, ACINQ también desaconsejó activar durante un splice la opción de compromiso sin comisiones, que ya venía deshabilitada por defecto.
El cierre forzoso vuelve a un estado de financiación confirmado
La actualización también cambia la gestión de los canales que deben cerrarse mientras su transacción de financiación sigue sin confirmarse. Con la nueva lógica, Eclair selecciona una transacción de compromiso que su backend de Bitcoin Core reconoce como financiada. Si hace falta, utiliza el último estado de financiación confirmado en lugar de liquidar el canal contra una transacción que ya ha desaparecido del mempool local.
Otra corrección aborda transacciones que los mineros pueden confirmar aunque Eclair ya no las considere la vía de liquidación preferida. Con la lógica anterior, podían clasificarse por error como transacciones de la contraparte, de modo que algunos fondos recuperables y salidas vinculadas a pagos pendientes quedaban sin reclamar. La nueva versión las identifica e intenta recuperar las salidas asociadas.
No es necesario cerrar los canales para actualizar
ACINQ indicó que los nodos que todavía usan versiones anteriores de Eclair deben instalar la actualización y mantener activada por defecto la protección que exige entradas confirmadas. Para actualizar, los operadores deben detener el software, instalar la nueva versión y reiniciar el nodo. No es necesario cerrar los canales de pago existentes.
El investigador de seguridad Erick Cestari comunicó de forma responsable los problemas corregidos. ACINQ advirtió de que algunos podían ser aprovechados por nodos maliciosos, pero no precisó cuántos nodos podrían haberse visto afectados ni si se produjo algún ataque.