Eclair incorporó dos correcciones para evitar que los nodos Lightning paguen comisiones excesivas a los mineros de Bitcoin al financiar canales o realizar operaciones de splicing. Los cambios se integraron en la rama principal del proyecto el 2 y el 5 de octubre. Sin embargo, a 12 de octubre, la página de versiones seguía mostrando la v0.14.3, publicada en septiembre, como la más reciente; por tanto, no está confirmado que las correcciones formen parte de una versión distribuida.
Desarrollado por ACINQ, Eclair es un software para operar nodos Lightning. Las correcciones afectan a las comisiones en canales con financiación dual y en el splicing, además de a la verificación de transacciones en el modo Eclair-signer. Cualquier pérdida derivada de estos problemas se pagaría como comisión de minería, no se transferiría directamente a un atacante.
PR #3388 limita las subidas de comisión propuestas por la contraparte
La primera corrección, PR #3388, aborda las transacciones de reemplazo por comisión (RBF, por sus siglas en inglés) iniciadas por una contraparte. Al abrir un canal con financiación dual o modificar su financiación mediante splicing, la otra parte puede proponer una transacción de reemplazo con una comisión más alta. Antes del cambio, un nodo Eclair que aportara fondos podía acabar pagando más por su parte de la transacción, sin un límite explícito ni un presupuesto definido para este proceso.
Así, una contraparte maliciosa podía presionar al nodo que financiaba el canal para que aceptara una tasa de comisión de minería arbitrariamente alta, sin asumir el coste adicional. La pérdida del nodo se destinaría a los mineros como comisión de transacción, no directamente a la contraparte.
Con la corrección, Eclair rechaza las solicitudes que superen el límite de tasa de comisión recomendado para la transacción de financiación. La restricción no se aplica si la contraparte paga por la liquidez y cubre la comisión correspondiente a la aportación de Eclair, ni cuando el nodo Eclair no contribuye a la transacción. En esos casos, el nodo no soporta el coste de comisión que busca limitar el cambio.
PR #3390 verifica la comisión real en modo signer
La segunda corrección, PR #3390, se refiere al modo Eclair-signer. En esta configuración, el backend Bitcoin Core (bitcoind) selecciona los bitcoins y construye la transacción, mientras Eclair conserva las claves privadas y la firma. Que las claves de firma permanezcan en Eclair no basta para proteger el sistema si el backend está comprometido: este podría informar de una comisión dentro del presupuesto y, al mismo tiempo, construir una transacción que pague más, por ejemplo, eliminando una salida de cambio para aumentar la comisión de minería.
En una transacción de Bitcoin, el valor de las entradas que no se asigna a ninguna salida se convierte en la comisión para los mineros. Por eso, eliminar el cambio puede costarle dinero al nodo sin enviar esos fondos a una dirección controlada por un atacante.
La corrección calcula la comisión efectiva a partir del valor de las entradas gastadas y recupera las transacciones pertinentes mediante su identificador para verificar esos importes. Después, Eclair compara la comisión comunicada por el backend con la calculada y aplica el presupuesto al importe real, en lugar de confiar únicamente en la cifra del backend. También comprueba que la parte de financiación reconstruida por Eclair pague la misma comisión verificada y rechaza transacciones cuya salida de cambio esté en una posición no válida.
Los cambios de octubre aún no figuran en una versión publicada
Las dos modificaciones establecen límites de comisión para la financiación dual y el splicing, y verifican el coste de las transacciones en modo signer. Son independientes de una vulnerabilidad anterior relacionada con las comisiones de los cierres cooperativos de canales y del problema de denegación de servicio divulgado el 2 de octubre, que podía afectar a los nodos después de reiniciarse.
A 12 de octubre, la página de versiones de Eclair seguía indicando que la v0.14.3, publicada en septiembre, era la última versión. La integración de cambios en la rama principal no confirma que estén disponibles en un paquete publicado. Los operadores de nodos deberán comprobar si la versión instalada incluye las modificaciones de octubre.