Por Canuto  

Eclair fusionó dos cambios para limitar tarifas abusivas durante la financiación de canales Lightning y verificar que un backend de Bitcoin cobre lo que declara. Sin embargo, las correcciones todavía no confirmaban su inclusión en una versión publicada, según la información disponible al 12 de octubre.
***

  • Un cambio limita las tarifas que un par puede exigir mediante reemplazos RBF cuando Eclair aporta fondos a una apertura o a un splice.
  • Otro verifica en modo Eclair-signer que las tarifas reales coincidan con el presupuesto y con lo informado por el backend de Bitcoin.
  • Las reparaciones se fusionaron en octubre, pero la última versión publicada que figuraba al 12 de octubre era la v0.14.3, de septiembre.

Dos cambios fusionados en Eclair buscan evitar que un nodo pierda Bitcoin al pagar tarifas de minería excesivas durante la financiación de canales Lightning. Según la descripción de las reparaciones, las defensas cubren tanto las exigencias de reemplazo de un par como las discrepancias que podría introducir un backend comprometido, pero todavía no se confirmaba que estuvieran empaquetadas en una nueva versión.

  • La primera reparación establece un límite para ciertas subidas de tarifas solicitadas durante aperturas de financiación dual y splices.
  • La segunda comprueba el costo real de una transacción cuando Eclair conserva las claves y un backend externo la construye.
  • Al 12 de octubre, la versión publicada más reciente que aparecía en la página del proyecto era la v0.14.3, lanzada en septiembre.

Eclair añade límites para evitar pérdidas por tarifas en Lightning

Dos riesgos distintos durante la financiación

Eclair, una implementación de Lightning desarrollada por ACINQ, incorporó dos reparaciones a la rama principal de su proyecto. Ambas apuntan a situaciones en las que un operador podría perder BTC debido a tarifas de minería demasiado altas, aunque responden a mecanismos distintos: una limita las solicitudes de aumento de tarifas de un par y la otra verifica la transacción preparada por un backend de Bitcoin.

La red Lightning permite realizar pagos fuera de la cadena principal de Bitcoin mediante canales financiados con fondos que luego pueden ajustarse o cerrarse. En ese contexto, la apertura de un canal con financiación dual puede involucrar aportes de ambas partes, mientras que un splice modifica la financiación asociada a un canal existente; ambos procesos requieren transacciones en la cadena de Bitcoin y, por tanto, pueden implicar tarifas de minería.

Las reparaciones no describen un traspaso directo de los fondos del nodo a la cartera del par, sino pérdidas que pueden producirse al pagar tarifas. En el escenario de la primera corrección, el costo excesivo iría a los mineros como tarifa de la transacción, mientras que la otra aborda la posibilidad de que una transacción consuma valor que no se asignó a ninguna salida.

CryptoSlate informó que los cambios se fusionaron en la rama master los días 2 y 5 de octubre, y que el boletín de Bitcoin Optech del 9 de octubre destacó ambos como protecciones vinculadas a la financiación dual y al splicing. La fecha de fusión indica que el código entró en esa rama del proyecto; por sí sola, no confirma que los operadores ya lo recibieran en una versión lista para instalar.

El límite a los reemplazos de tarifa

La primera reparación, identificada como PR #3388, cubre intentos de reemplazo por tarifa, conocidos como RBF, que inicia un par durante una apertura con financiación dual o un splice. RBF permite proponer una transacción de reemplazo con una tarifa superior para mejorar sus posibilidades de confirmación, pero el cambio detectado en Eclair dejaba sin un límite superior la tarifa que podía terminar pagando el nodo que aportaba fondos.

Según la descripción del problema, Eclair mantenía su contribución de cartera y podía pagar sus entradas conforme a la tarifa más alta que pidiera el par. En esa ruta no había un presupuesto de tarifas que acotara el costo, de modo que un par malicioso podía imponer un gasto de minería arbitrario al nodo financiador sin contribuir dinero a la transacción.

La corrección rechaza los intentos de reemplazo que superen la tarifa máxima de financiación que Eclair recomienda a su par. La medida busca impedir que una solicitud de aumento convierta una operación ordinaria de apertura o ajuste de canal en un gasto ilimitado para el nodo que aporta fondos.

El límite contempla dos excepciones en las que Eclair no asume el costo que esta defensa busca contener. Una corresponde al caso en que el par compra liquidez y paga las tarifas de las entradas de Eclair; la otra, a una transacción a la que el nodo Eclair no aporta fondos.

Comprobaciones para el modo Eclair-signer

La segunda reparación, PR #3390, trata una amenaza diferente en el modo Eclair-signer. En esa configuración, bitcoind, el backend de Bitcoin Core, selecciona las monedas y construye las transacciones, mientras Eclair conserva las claves y se encarga de firmar; por eso, proteger las claves no basta para garantizar que la transacción propuesta respete el presupuesto de tarifas.

Un backend comprometido podría informar que una operación está dentro del presupuesto y, al mismo tiempo, construir una transacción que en realidad paga más. Una forma de lograrlo sería eliminar la salida de cambio: en Bitcoin, el valor de las entradas que no se asigna a salidas se convierte en tarifa para los mineros, por lo que la ausencia de ese cambio puede consumir fondos sin enviarlos a una dirección de un atacante.

Cuando se proporciona un presupuesto de tarifas, la nueva comprobación calcula el costo real a partir del valor de las monedas gastadas. Eclair obtiene esos valores mediante los identificadores de las transacciones correspondientes, una verificación destinada a autenticar el monto de las entradas, y compara el resultado con la tarifa reportada por el backend antes de aplicar el presupuesto a la tarifa efectiva.

La reparación también comprueba que las contribuciones reconstruidas por Eclair paguen la misma tarifa que la transacción verificada, y rechaza posiciones inválidas de la salida de cambio. Estas comprobaciones buscan detectar discrepancias entre lo que reporta el backend y el gasto que resultaría de la transacción firmada, sin depender únicamente de que el componente externo describa correctamente su propio trabajo.

Fusiones no equivalen a una actualización instalada

La diferencia entre una corrección fusionada y una versión publicada es relevante para quienes operan nodos. Al 12 de octubre, la página de lanzamientos citada en la información de CryptoSlate seguía mostrando la v0.14.3 de septiembre como la versión más reciente, por lo que las dos fusiones de octubre no demostraban que existiera ya un paquete actualizado disponible para todos.

En consecuencia, los operadores deben verificar si la compilación que tienen instalada contiene los cambios de octubre, en lugar de asumir que el anuncio de una fusión actualizó automáticamente sus nodos. La información disponible identifica las reparaciones y sus solicitudes de cambio, pero no confirma una nueva versión que las incluya ni permite concluir que todos los despliegues estén protegidos.

Los cambios también deben distinguirse de otros problemas de Eclair que la cobertura mencionada trató por separado, entre ellos una falla de tarifas en cierres cooperativos y dificultades de denegación de servicio durante reinicios. Las dos nuevas reparaciones se enfocan específicamente en configuraciones de financiación dual, splicing y Eclair-signer, por lo que no deben presentarse como una solución general a todos los riesgos del software.

En términos prácticos, las defensas cubren dos puntos de confianza distintos: el margen que puede imponer un par durante una transacción de financiación y la exactitud de los datos que entrega el backend que la construye. Su alcance puede reducir esos riesgos cuando el código está presente, pero la confirmación de una versión publicada y la comprobación de cada instalación siguen siendo pasos separados.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados