Qué pasó
El 26 de agosto de 2026 Bitcoin Core fusionó bugfix: give TxDownloadManager its own RNG, ocho días después del cambio que lo hizo necesario. El gestor de descarga de transacciones mantenía una referencia al generador de números aleatorios del hilo de procesamiento de mensajes, que no es seguro entre hilos, mientras un segundo hilo podía alcanzar ese mismo objeto a través de otro cerrojo. El pull request lleva el hito 32.0, y el hallazgo vino del análisis estático de Project Loupe, no de algo que fallara en un nodo en marcha.
Qué cambia
La pregunta interesante es por qué un nodo necesita azar ahí. Cuando llega una transacción
cuyo padre falta, va al orfanato. Cuando el padre aparece más tarde, la huérfana debe
reconsiderarse, y Core la coloca en el conjunto de trabajo de un par que la había anunciado.
Si varios pares anunciaron la misma huérfana, elige a uno sacando un número:
std::advance(it, rng.randrange(num_announcers));. El propio código dice por qué no es
simplemente el primero que la anunció: "no queremos crear un problema en el que el par
asignado pueda impedirnos a propósito procesar la huérfana desconectándose". El azar está
ahí para que ningún par decida por sí solo si tu nodo llega alguna vez a una transacción.
La regresión vino de una mejora real. p2p: reconsider orphans when missing inputs are mined, fusionada el 18 de agosto de 2026, extendió la reconsideración al caso en que un padre que faltaba aparece por primera vez en un bloque y no en la mempool. Ese camino corre en el hilo de fondo de validación. El generador que tomaba prestado pertenece al procesamiento de mensajes y está protegido por otro mutex, así que los dos hilos sostenían cada uno un cerrojo y ninguno excluía al otro.
Eso es una condición de carrera, y la
descripción honesta no es que dos hilos puedan sacar el mismo número. En C++ una carrera de
datos es comportamiento indefinido, así que el programa no tiene significado definido en ese
punto, haga lo que haga en la práctica. La corrección es una línea de propiedad: el gestor de
descarga ahora tiene su propio FastRandomContext en lugar de una referencia al de otro.
Qué no cambia
Ninguna versión publicada quedó afectada. Bitcoin Core 31.1, la versión actual, se publicó el 8 de julio de 2026, antes de cualquiera de los dos cambios. Tanto la regresión como la corrección vivieron en la rama de desarrollo, con una semana de diferencia, y la versión a la que apuntan todavía no ha salido.
Nada del consenso se movió. En qué conjunto de trabajo cae una huérfana es comportamiento de retransmisión, no una regla de validación: ninguna moneda fue gastable o ingastable por esto, y dos nodos que discreparan en el sorteo seguirían coincidiendo sobre la cadena.
Tampoco dice que el cambio sobre huérfanas fuera un error. Reconsiderar las huérfanas cuando su padre se mina es el comportamiento correcto, y se quedó. Lo que se movió fue de dónde sale el azar.
Contexto
La mejora sobre huérfanas tiene un origen visible. Un revisor señaló que cuando "los padres de las huérfanas nunca entraron en la mempool y se vieron por primera vez en bloques minados, sus hijas ya válidas no se reconsideraban y se quedaban en el orfanato", y que esto "fue probablemente más visible durante la reciente oleada de rescates de COLDCARD por Slipstream". Las monedas que se barrían de dispositivos con seeds débiles se entregaban directamente a un minero en lugar de difundirse, así que la transacción padre aparecía por primera vez en un bloque y todo lo que dependía de ella se quedaba atascado.
El resto es un patrón de este mes: dos pull requests pequeños, con ocho días de diferencia, donde el segundo existe porque el primero amplió quién toca un objeto compartido. La misma forma aparece en una invariante que solo vivía en la cabeza de los revisores hasta que alguien escribió la prueba. La corrección en un código tan viejo es sobre todo una cuestión de qué supuestos están escritos en algún sitio que una máquina pueda comprobar.