Firmware y ajustes

Core Lightning 26.06.9 corrige vulnerabilidades de nodos de pago y retrasos de tráfico

Publicación de la fuente: 2026-10-07 · Análisis editorial publicado: 2026-10-09

La versión del 7 de octubre repara la regresión de chismes del 26.06.8, fortalece las salvaguardas del canal y de la API y agrega compilaciones ARM firmadas. Los mantenedores recomiendan actualizar rápidamente.

Análisis e implicaciones prácticas

Esta sección contiene nuestro análisis y cálculos ilustrativos, separados del informe original.

Una actualización publicada para la capa de pago

Core Lightning publicó la versión 26.06.9 en GitHub el 7 de octubre de 2026. Su registro de cambios etiquetado tiene fecha del 6 de octubre. Los mantenedores recomiendan instalar esta versión puntual lo antes posible; incluye correcciones de seguridad y repara una regresión del procesamiento de mensajes introducida en 26.06.8. Este es un software de nodo de pago, no un firmware ASIC o un cambio de consenso de Bitcoin. La distinción es importante para una empresa de minería de criptomonedas que ejecuta un servicio Lightning junto con su potencia de hash: la actualización del servidor de pago no cambia la tasa de hash, la configuración de energía o la recompensa de bloque del minero.

ASIC.tools verificó el lanzamiento y el registro de cambios versionado directamente. El análisis práctico a continuación se refiere a la operación de un nodo y los servicios circundantes, en lugar de prometer un aumento en los ingresos mineros. Es posible que una granja que recibe solo pagos ordinarios en cadena no tenga una implementación de Core Lightning para actualizar. Una empresa que acepte pagos Lightning por alojamiento, calefacción o servicios debe identificar primero la implementación y la versión reales, porque los productos Bitcoin con nombres similares tienen cronogramas de lanzamiento y procedimientos de migración separados.

Por qué los nodos ocupados podrían retrasar los mensajes

El comunicado describe una corrección en el presupuesto de CPU para consultas gossip: el tráfico gossip ordinario, los pings y los mensajes onion ya no consumen la asignación destinada a las consultas gossip. En 26.06.8, un nodo ocupado podría limitar los pares y retrasar el tráfico del canal. Por lo tanto, la regresión documentada se refiere al manejo de la carga de trabajo en esa versión, más que a la evidencia de que todos los pagos Lightning se interrumpieron o que los bloques de Bitcoin dejaron de llegar. La actualización apunta a ese error contable en particular y al mismo tiempo conserva un presupuesto para las consultas que debía controlar.

Para los operadores, una distinción útil es entre un tiempo de espera de solicitud y un pago fallido. Si un pago espera más de lo esperado, volver a intentarlo a ciegas puede crear una secuencia confusa de facturas, intentos pendientes y registros contables. Una mejor verificación operativa vincula el identificador de pago, el estado de la factura y la liquidación final antes de tratar un tiempo de espera como una nueva venta. Después de una actualización, compare la misma carga de trabajo y el mismo intervalo de observación: las respuestas rápidas ocasionales por sí solas no prueban que los períodos de mayor actividad ahora se manejen correctamente.

Cierre de canales y plazos de pago

El registro de cambios corrige el manejo de un HTLC ofrecido que alcanza su plazo durante el cierre de un canal: el nodo ahora fuerza el cierre del canal para proteger los fondos reenviados de un cumplimiento tardío. Un HTLC es un contrato de pago condicional, no un share de ASIC enviado a un pool de minería. La corrección afecta al límite entre la operación del canal fuera de la cadena y la ejecución en cadena. No garantiza recuperar dinero ya perdido ni significa que todos los canales cerrados fueran vulnerables.

La contabilidad de un operador debe reflejar ambos niveles. La liquidez del canal no es idéntica a un saldo en cadena gastable confirmado, y una transacción de cierre puede introducir tarifas de transacción y períodos de espera. Para un servicio de hospedaje de minería, esa distinción afecta el saldo de trabajo disponible para electricidad y reembolsos a los clientes. La respuesta operativa sensata es conciliar el estado del canal y los registros de liquidación con el libro mayor de la aplicación, en lugar de inferir la solvencia a partir de un único número del panel o de un pago de prueba exitoso.

Los permisos de API merecen una revisión aparte

El lanzamiento refuerza la autorización de API basada en runas y enmascara varios valores de configuración confidenciales. El registro de cambios también cierra una ruta de inyección de configuración persistente y verifica los alias de los métodos con las restricciones relevantes. Estos son cambios en la administración del servidor; una runa en este contexto es una credencial de autorización, no un token de criptomoneda. Los operadores deben comparar los cambios de método mencionados con sus propias integraciones, especialmente cuando un servicio de monitoreo o facturación utiliza una credencial restringida deliberadamente.

Independientemente de este parche en particular, un servicio de facturación no suele necesitar los mismos privilegios que un administrador humano. Dividir el monitoreo de solo lectura de la ejecución de pagos y los cambios de configuración hace que la integración sea más fácil de auditar. La actualización es una oportunidad para comprobar qué proceso posee cada credencial, dónde se almacena y cómo se revoca. Una pantalla de monitoreo saludable debería demostrar que las llamadas requeridas aún funcionan con los límites previstos; no debería depender de reemplazar silenciosamente una credencial restringida con acceso sin restricciones.

Llegan los binarios firmados para más arquitecturas

El lanzamiento agrega binarios reproducibles arm64 y armv7 para Ubuntu 22.04, 24.04 y 26.04 junto con amd64. Cada arquitectura tiene su propio manifiesto de suma de comprobación firmado. El procedimiento de verificación publicado verifica la firma del manifiesto y luego las sumas de verificación del archivo. Los archivos específicos de la arquitectura son importantes: un dispositivo ARM y un servidor x86 no pueden simplemente intercambiar archivos binarios porque ambos ejecutan Linux. Los operadores también necesitan que el paquete coincida con su distribución y método de implementación, en lugar de seleccionar solo la descarga más nueva.

Una suma de comprobación responde si los bytes descargados coinciden con un manifiesto; una firma verificada conecta ese manifiesto con la clave de firma en la que ha elegido confiar. Ambos controles tienen un propósito. Guardar el nombre exacto del artefacto, la versión y el resultado de la validación hace que la resolución de problemas posterior sea más precisa que escribir "actualizado a la última versión". Esto es particularmente útil cuando se instalaron varias máquinas en diferentes momentos, o cuando una imagen de contenedor y un paquete de host tienen mecanismos de actualización separados y en realidad pueden contener versiones diferentes.

La compatibilidad de la base de datos limita la reversión

Los mantenedores advierten que los nodos que han ejecutado compilaciones de la rama de desarrollo master no pueden degradar a una versión 26.06.x debido a un esquema de base de datos más nuevo. También mantienen precauciones sobre la financiación dual experimental y los canales de confirmación cero con pares que no son de confianza. Esto no significa que el comunicado público en sí sea una instantánea del desarrollo. Significa que la ruta de actualización depende del historial del nodo, por lo que un binario que funcione por sí solo no puede establecer si abrir un directorio de datos existente es compatible.

Como principio operativo, registre la versión inicial, el origen del paquete, los complementos habilitados y el diseño del almacenamiento antes de cambiar el software. Las copias de seguridad deben seguir las propias pautas de coherencia y recuperación de la aplicación; copiar archivos arbitrarios de bases de datos activas no es automáticamente un plan de recuperación válido. Del mismo modo, restaurar el estado de un canal antiguo no equivale a restaurar un sitio web estático. Trate la capacidad de revertir el sistema operativo por separado de la capacidad de revertir el estado de pago y pruebe los procedimientos de mantenimiento en una configuración adecuada que no sea de producción.

Un útil control de aceptación después del mantenimiento

Nuestra verificación de aceptación sugerida se centra en el servicio que realmente proporciona el nodo. Confirme que llegue a su backend de Bitcoin, se vuelva a conectar con los pares esperados y exponga solo las interfaces de administración previstas. Luego verifique una factura controlada y su estado final a través de la misma aplicación que utilizan los clientes. Observe los registros de errores, los pagos pendientes y los resultados de conciliación durante un intervalo de actividad representativo. Estas son comprobaciones prácticas para su implementación, no cifras de rendimiento medidas por Core Lightning o una promesa de que todos los complementos de terceros son compatibles.

Para una granja, mantenga la disponibilidad de pago y la disponibilidad de minería como indicadores diferentes. Una factura de cliente retrasada puede requerir atención mientras la flota de ASIC continúa con el hash normalmente; por el contrario, los pagos exitosos no le dicen nada sobre una bomba de enfriamiento defectuosa o shares rechazadas. Informar los dos por separado ayuda al personal a diagnosticar el sistema correcto y evita culpar a una versión de firmware ASIC por un problema en el nodo de pago. También brinda a los clientes una explicación más clara cuando una ventana de mantenimiento afecta un servicio de pago pero deja en funcionamiento su equipo de minería alojado.

Lo que establece y lo que no establece el anuncio

La actualización está disponible, pero los encargados del mantenimiento han retenido temporalmente las pruebas de seguridad para dar tiempo a los operadores a instalar las correcciones. Esa elección de publicación no es evidencia de una versión futura inédita ni una razón para esperar demostraciones de exploits. Siga las notas de la versión oficial para conocer las decisiones de instalación y compatibilidad. El apodo descriptivo del comunicado no es, por sí solo, una prueba de que la minería de Bitcoin o cada transacción Lightning haya adquirido una nueva garantía de seguridad cuántica; El comportamiento técnico debe establecerse a partir de la implementación y documentación.

Este artículo utiliza distintas fotografías de archivo con licencia de equipos informáticos y de red. Ilustran el entorno operativo y no representan al equipo de lanzamiento ni a una instalación comprometida. ASIC.tools tratará los lanzamientos puntuales posteriores como eventos separados cuando se confirmen sus registros de cambios y fechas de publicación. Para esta versión, la decisión inmediata es concreta: identifique si su servicio ejecuta Core Lightning, revise los cambios documentados y elija una ruta de mantenimiento compatible con artefactos de instalación verificados.

Fuente: Core Lightning ↗ · Versioned 26.06.9 changelog ↗