Bitcoin Core ha publicado los detalles de un bug de alta gravedad que podía dejar a un nodo sin capacidad de construir bloques nuevos. El fallo se corrigió hace más de un año, pero la alerta no llegó hasta el 10 de noviembre, una vez que la última versión vulnerable había quedado sin soporte. Los afectados son, sobre todo, mineros y operadores de pools.
El identificador es CVE-2025-62861. Para entenderlo conviene recordar qué ocurre cuando la red cambia de cadena: en una reorganización (un reorg), bitcoin descarta unos bloques recientes y adopta otra rama con más trabajo acumulado. Las transacciones que iban dentro de esos bloques vuelven al mempool, la sala de espera donde los nodos guardan las operaciones pendientes de confirmar.
Una regla de expulsión que se rompía al reconstruir el mempool
El origen está en las transacciones TRUC, de topología restringida: solo admiten un hijo sin confirmar por cada transacción padre. Sobre ellas actúa una regla bautizada como sibling eviction. Si llega un segundo hijo con más comisión, el nodo expulsa al primero. Ese mecanismo, introducido en la versión 28.0, fallaba justo cuando tocaba restaurar transacciones de bloques desconectados.
El nodo eliminaba una transacción restaurada y, sin embargo, mantenía vivos a sus descendientes. Esas operaciones hijas gastaban fondos que ya no existían en su copia de la cadena. Con esa base contaminada, la plantilla de bloque —el bloque candidato que el nodo entrega a los mineros para que trabajen sobre él— no superaba la verificación de validez. Sin plantilla no hay bloque; sin bloque no hay recompensa.
El único remedio para un nodo ya afectado era reiniciarlo, lo que le obliga a levantar el mempool desde cero. Conviene subrayarlo: no se perdían monedas ni llaves. El problema era de software que se quedaba mirando a la pared en el peor momento posible.
Las versiones afectadas son la 28.0 a la 28.2 y la 29.0 a la 29.1. Niklas Goegge, investigador de seguridad, reportó el fallo de forma responsable el 26 de septiembre de 2025; el desarrollador Greg Sanders firmó la solución. Los parches salieron el 10 de octubre de 2025 en las versiones 30.0, 29.2 y 28.3.
Un bug que impide fabricar bloques no roba bitcoin: rompe la maquinaria con la que se producen. La diferencia importa, y mucho.
¿Por qué contarlo trece meses después? Porque Bitcoin Core espera a que la rama vulnerable deje de tener soporte antes de airear los detalles técnicos. Es la misma lógica que siguen los grandes proyectos de software: dar tiempo a actualizar reduce la ventana de ataque. A cambio, durante meses el usuario no sabe exactamente qué riesgo corre.
Quién estaba en riesgo y qué debería hacer ahora
Los damnificados potenciales son los nodos que fabrican plantillas de bloque, es decir, mineros y pools de minería que operaban con las versiones antiguas. Un nodo de usuario corriente, que solo valida y difunde transacciones, no dependía de esa función, aunque arrastraba la inconsistencia del mempool.
La recomendación es sencilla: actualizar a la versión 30.0 o posterior, disponible en la web oficial de Bitcoin Core. Quien siga con la 28.0, 28.1, 28.2, 29.0 o 29.1 debería hacerlo ya. Y si el nodo ya mostraba problemas, un reinicio devuelve un mempool limpio.
El reparto geográfico de nodos ayuda a calibrar la magnitud. Según datos de Newhedge, Estados Unidos concentra el 32,63% de los nodos de bitcoin, seguido de Alemania y Francia. Esa métrica mide nodos alcanzables y no cuántos operan con cada versión, pero da una idea de dónde se sienta la infraestructura que sostiene la red.
El patrón se repite: parche primero, explicación mucho después
No es la primera vez que el proyecto aplica esta secuencia. En septiembre de 2018, Bitcoin Core reveló un error de inflación que había corregido meses antes con la versión 0.16.3; el riesgo era entonces teórico, pero el episodio dejó una lección clara: un fallo de consenso puede ser letal si alguien aprende a convertirlo en arma. Sirve como marco para leer lo de hoy sin alarmismo. Este bug no rompe el consenso, no duplica monedas, y no permite crear dinero de la nada.
Lo que sí revela es una fragilidad más mundana: la dependencia de que miles de operadores actualicen a tiempo. En el mismo lote de comunicados, Bitcoin Core detalló otros dos fallos corregidos en la 30.0. Uno podía detener el procesamiento de bloques; el otro concedía permisos indebidos a conexiones entrantes por Tor, la red de anonimato. El pasado octubre llegó además otro paquete con tres errores más, detectados por un escáner impulsado por inteligencia artificial llamado Project Loupe. El historial completo de cada versión se publica en el repositorio oficial del proyecto en GitHub.
Hay una lectura tranquilizadora y otra incómoda. La buena: el circuito de notificación funcionó (investigador, mantenedores, parche, silencio y divulgación final). La mala: los nodos viejos no desaparecen solos, y cada versión sin soporte es una puerta que nadie vigila. Nadie gana dinero actualizando un nodo; sí se gana minando.
La pregunta abierta no es si habrá otro CVE, sino cuántos operadores habrán saltado de la rama 29.x a la 30.x antes de que aparezca el siguiente. La respuesta tardará. Y mientras, el mempool sigue ahí, esperando la próxima reorganización.
