Eclair, el software de nodos de Lightning desarrollado por ACINQ, ha incorporado dos correcciones para evitar que ciertos fallos en la financiación de canales y en los splices obliguen a un nodo a pagar comisiones de minería excesivas en bitcoin. Ninguno de los dos escenarios requería que un atacante obtuviera las claves privadas del nodo.
Los cambios se integraron en la rama principal del proyecto los días 2 y 5 de octubre. Sin embargo, a 12 de octubre la página de versiones de Eclair seguía mostrando la versión 0.14.3, publicada en septiembre, como la más reciente. Por tanto, las dos correcciones de octubre todavía no formaban parte de esa versión empaquetada.
Un límite a las comisiones impuestas por el otro participante
La primera reparación, identificada como PR #3388, afecta a las aperturas de canales con financiación aportada por ambas partes y a los splices, operaciones que modifican la transacción de financiación de un canal.
En estos procesos, el otro nodo podía solicitar una sustitución de la transacción mediante replace-by-fee (RBF), elevando la comisión por unidad de datos. Eclair conservaba su aportación al canal y pagaba también las comisiones correspondientes a sus propias entradas, pero en ese recorrido no existía un límite superior ni un presupuesto máximo suficientemente acotado.
Un participante malicioso podía aprovechar esa situación para imponer una comisión arbitrariamente alta al nodo que aportaba fondos, incluso sin contribuir con dinero a la operación. La pérdida no se transfería directamente al atacante: el importe terminaba en manos de los mineros como comisión de la transacción.
La corrección rechaza las solicitudes que superen la tasa máxima de comisión que Eclair recomienda al otro participante. El límite no se aplica en dos casos: cuando ese participante compra liquidez y asume las comisiones de las entradas de Eclair, o cuando el nodo de Eclair no aporta fondos a la transacción. En ambos supuestos, el coste que corrige el cambio no recae sobre Eclair.
La firma del nodo no basta frente a un backend comprometido
La segunda modificación, PR #3390, se dirige a las configuraciones en las que Eclair utiliza el modo signer. En ese diseño, Bitcoin Core —a través de bitcoind— selecciona las monedas y construye las transacciones, mientras Eclair conserva las claves y se encarga de firmarlas.
El problema es que un backend de Bitcoin comprometido podía informar de una comisión dentro del presupuesto permitido y, al mismo tiempo, construir una transacción cuyo coste real fuese mucho mayor. Una de las vías consistía en eliminar la salida de cambio. En el modelo contable de Bitcoin, el valor de las entradas que no se asigna a ninguna salida se considera una comisión para los mineros. De ese modo, los fondos podían desaparecer sin que el atacante tuviera que enviárselos a una dirección bajo su control.
La reparación calcula la comisión efectiva a partir del valor de las monedas gastadas. Para autenticar esos importes, los obtiene mediante los identificadores de las transacciones correspondientes. Después compara la comisión real con la comunicada por el backend y aplica el presupuesto a la cifra verificada, no a la que declara el componente externo.
Eclair también comprueba que las aportaciones reconstruidas por el nodo pagan esa misma comisión validada y rechaza posiciones no válidas de las salidas de cambio.
Correcciones todavía no incluidas en la versión publicada
El boletín de Bitcoin Optech del 9 de octubre destacó ambos cambios como cierres de brechas de protección en la financiación conjunta y en los splices. Se trata de problemas distintos del fallo de comisiones en cierres cooperativos mencionado en un informe anterior y de los errores de denegación de servicio durante reinicios.
Las correcciones descritas afectan a nodos Eclair que utilizan financiación dual, splicing o el modo signer. Los operadores deben comprobar si la compilación instalada incorpora los cambios de octubre, ya que la versión 0.14.3 seguía figurando como la última publicación disponible en la fecha indicada.
