Bitcoin Core ha publicado la divulgación oficial de CVE-2025-62861, una falla de severidad alta en la lógica de retransmisión de transacciones del software del nodo que podía dejar a las operaciones de minería trabajando sobre plantillas de bloques obsoletas sin ningún aviso visible. La advertencia acredita al investigador de seguridad Niklas Goegge con el reporte del problema y lo atribuye a una regla de retransmisión que se activó en el momento equivocado: durante una reorganización de la cadena, cuando debía permanecer silenciosa.

Las versiones afectadas van desde Bitcoin Core 28.0 hasta 28.2 y desde 29.0 hasta 29.1. La corrección se lanzó en octubre de 2025, pero los detalles técnicos completos se mantuvieron en reserva hasta noviembre de 2026 bajo la política de divulgación coordinada del proyecto. La advertencia no menciona ninguna interrupción ni operador afectado; la exposición es histórica. El hardware de minería conectado a un nodo en ese estado corrupto habría seguido minando, pero sobre la última plantilla que recibió, por lo que las nuevas transacciones y sus comisiones habrían quedado sin reclamar hasta que alguien lo notara.

Cómo una reorganización puede dejar huérfana una transacción

Una reorganización ocurre cuando un nodo abandona su punta de cadena actual por una rama competidora más pesada. Las transacciones de los bloques desconectados siguen siendo válidas, por lo que Bitcoin Core las devuelve a la mempool, su área de retención para transacciones sin confirmar. Como esas transacciones ya estaban confirmadas en un bloque válido, el nodo las vuelve a agregar con una bandera llamada bypass_limits, que desactiva los controles habituales contra spam y de topología. El propósito es restaurar el pool fielmente, no volver a juzgar transacciones que ya superaron el consenso.

Uno de los controles que debía haberse desactivado se refiere a las transacciones de versión tres, o TRUC. Según BIP 431, una transacción TRUC puede tener como máximo un padre sin confirmar y un hijo sin confirmar. Esa es una política de retransmisión, no una regla de consenso: un bloque puede contener legítimamente un padre TRUC con varios hijos, aunque ningún nodo aceptaría esa forma en su mempool desde la red. Esa misma frontera entre política y consenso marcó el límite de la falla en sí: CVE-2025-62861 podía corromper la mempool de un nodo y detener la generación de sus plantillas, pero no podía crear un bloque inválido ni alterar las reglas de la cadena.

Desde la versión 28.0, Bitcoin Core ha aplicado el límite de un hijo mediante un mecanismo llamado expulsión de hermanos (sibling eviction). Cuando una nueva transacción daría a un padre TRUC un segundo hijo sin confirmar, el nodo trata al hijo existente como candidato de reemplazo y, si la nueva paga suficiente en comisiones, lo expulsa bajo las reglas de reemplazo por comisión (replace-by-fee).

La falla era que la expulsión de hermanos se ejecutaba incluso cuando bypass_limits estaba activada. Una reorganización que restaurara un padre TRUC con varios hijos —una forma perfectamente válida dentro del bloque desconectado— podía desencadenar la expulsión de una transacción restaurada dejando en el pool las transacciones que gastaban sus salidas. La mempool quedaba entonces con hijos cuyo padre ya no existía en ningún lugar: ni en la cadena ni en el pool.

La corrección de Greg Sanders condicionó los controles TRUC a bypass_limits, de modo que la expulsión ya no se ejecuta durante la restauración tras una reorganización. El pull request asociado, PR #33504, también agregó el escenario de prueba que faltaba en el código original: transacciones que llegan desde bloques desconectados en lugar de hacerlo desde pares.

Cómo se ve una plantilla estancada desde el lado de la minería

Un nodo entrega trabajo al software de minería a través de getblocktemplate, que ensambla un bloque candidato, lo somete a la verificación de validez del propio nodo y devuelve el hash del bloque anterior, las transacciones elegidas y la siguiente altura. Con una transacción sin padre en el pool, el candidato ensamblado fallaba esa verificación, por lo que la llamada no podía devolver trabajo fresco.

Desde afuera, el nodo se veía sano:

• Proceso en ejecución
• Conexiones con pares abiertas
• Punta de cadena avanzando
• Mempool aceptando nuevas transacciones

Lo que en realidad estaba roto:

• La solicitud de plantilla devuelve un error
• Los hashers siguen trabajando sobre trabajo obsoleto
• No se puede encontrar ningún bloque en la punta actual
• El estado persiste hasta que se reinicie el nodo

Todo lo que un panel de monitoreo genérico observa habría permanecido en verde. La red tampoco devolvió ninguna señal: la punta de la cadena siguió avanzando —los bloques seguían encontrándose, solo que no por esta operación— de modo que el costo recayó únicamente en el minero estancado, en minería que no podía producir un bloque en la punta actual y en comisiones que de otro modo habría reclamado. Lo único que un minero necesita del nodo —una plantilla actual— era justamente lo que había dejado de producir.

Reinicio, parche y fin del ciclo de vida

Reiniciar el nodo vuelve a cargar la mempool desde el disco en un estado consistente, lo que elimina el síntoma. No hace nada sobre la causa: la siguiente reorganización con la misma forma de transacción podría volver a estancar el nodo.

La falla subyacente se eliminó en tres versiones. La versión 30.0 se lanzó con la corrección el 10 de octubre de 2025, y los backports llegaron después en 29.2 y 28.3. Desde el reporte privado hasta la última de esas versiones transcurrieron tres semanas:

Ambas ramas con backport han dejado de recibir soporte desde entonces. La política de mantenimiento de Bitcoin Core cubre las tres versiones principales más recientes —actualmente 30.x, 31.x y 32.x— y la rama 29.x llegó al fin de su ciclo de vida el 27 de octubre de 2026. Un operador que respondió a la falla original solo con un reinicio está ahora ejecutando código sin soporte, con una descripción pública de exactamente qué forma de transacción lo desencadena.

Por qué la advertencia esperó 396 días

Desde la primera versión corregida hasta la advertencia detallada transcurrieron 396 días, y la divulgación llegó exactamente dos semanas después de que la rama 29.x llegara al fin de su ciclo de vida. Ninguna de las dos cifras es una coincidencia. La política de divulgación de Bitcoin Core retiene los detalles de severidad media y alta hasta dos semanas después de que la última versión afectada deja de recibir soporte, con un preanuncio dos semanas antes, sincronizado con una nueva versión principal.

El embargo cubría la explicación, no el código. El pull request es público desde el 29 de septiembre de 2025, y las notas de la versión 28.3 y 29.2 ya mencionaban una corrección en la mempool en su momento. Lo que permaneció privado durante un año fue el documento que conecta el parche con un estancamiento de minería reproducible.

La política sí prevé una vía más rápida. Las fallas clasificadas como fácilmente descubribles —que el proyecto define como hallables con un esfuerzo mínimo— reciben una versión puntual y una advertencia inmediatas, sin embargo. Esta pasó por el cronograma estándar, por lo que los mantenedores no la consideraron trivial de encontrar. Se publicó junto con otras dos advertencias de severidad alta y media el mismo día, sobre un estancamiento en el procesamiento de bloques y un error de permisos de Tor; las tres fueron corregidas en el mismo ciclo de versiones de octubre de 2025. Por lo tanto, cualquier build lo suficientemente nuevo como para incluir el parche de la mempool también incluye las otras dos correcciones.

La vía más lenta encarna su propio supuesto: que los operadores actualizan dentro de la ventana de un año, de modo que cuando el disparador se describe públicamente, nadie vulnerable sigue escuchando.

Qué monitorear en lugar del tiempo de actividad

Para una operación de minería, la verificación útil no es si el nodo está vivo, sino qué tan antigua es su última plantilla exitosa. Un proceso en ejecución, conectado y sincronizado puede haber dejado de entregar trabajo, y esta falla fue una forma de que eso ocurriera en silencio. La versión del build pertenece a la misma verificación, porque un nodo al día en plantillas hoy puede ser un nodo fuera de soporte mañana.

Las fuentes de plantillas de respaldo requieren la misma pregunta. Un nodo de failover con la misma versión y la misma política de mempool habría enfrentado la misma reorganización y el mismo estancamiento; dos procesos en ejecución no son dos fuentes independientes de trabajo. Solo un nodo con un build diferente y parcheado habría mantenido la operación minando, y solo un operador que lo hubiera probado bajo una reorganización simulada lo habría sabido de antemano.