Bitcoin Core 32.1, publicada el 27 de octubre de 2026: por qué se retiró la 32.0, los tres fallos divulgados y el nuevo estimador de comisiones

1. ¿Qué es Bitcoin Core 32.1 y por qué no hay 32.0?

Bitcoin Core es la implementación de referencia de Bitcoin, el software que valida bloques, retransmite transacciones y ejecuta la wallet que hay detrás de muchos servicios. Publica una versión mayor cada seis meses aproximadamente y mantiene las tres más recientes. La versión 32.1, publicada el 27 de octubre de 2026, es la primera release pública de la línea 32.x, con un nuevo estimador de comisiones, más conexiones por defecto, un índice de transacciones más pequeño, PSBT versión 2 como valor por defecto en las RPC de la wallet y un lote de correcciones de seguridad. No cambia ninguna regla de consenso: los bloques y las transacciones válidos antes siguen siéndolo después.

La 32.0 existe solo como etiqueta. El mantenedor fanquake la etiquetó el 21 de octubre y escribió en el issue del calendario de releases el 26 de octubre que, por problemas de última hora, la 32.0 no se anunciaría ni se publicaría y no se subirían binarios; la 32.1 seguiría con el mismo contenido más correcciones adicionales. El pull request que cerró la 32.1, fusionado esa misma tarde, incorpora por backport exactamente tres cambios de Antoine Poinsot: la vigilancia de excepciones de socket alineada entre los backends poll y select, un tiempo límite de 20 minutos para los peers cuyo búfer de envío nunca se vacía, y posiciones de 64 bits en los archivos de bloques y undo. Son las correcciones de las tres vulnerabilidades divulgadas dos días después, descritas en la sección 3. El proyecto no ha dicho más sobre los motivos.

2. ¿Cuándo se publicó? Fechas clave

Las fechas salen del issue del calendario de releases de Bitcoin Core, del servidor de descargas de bitcoincore.org y de las publicaciones de divulgación. Estado a 2 de noviembre de 2026.

3. ¿Qué vulnerabilidades se corrigieron y divulgaron?

Tres, todas publicadas el 28 de octubre de 2026 y todas encontradas por la misma vía: un escaneo automatizado del código con un modelo de lenguaje de gran tamaño, ejecutado como Project Loupe por Elias Rohrer en Spiral, con Gregory Sanders validando cada hallazgo y comunicándolo al equipo de seguridad de Bitcoin Core. Dos las redescubrieron de forma independiente otros investigadores antes de que salieran las correcciones. La política de Bitcoin Core es divulgar los fallos que considera fáciles de descubrir en cuanto existen releases corregidas para todas las ramas mantenidas, y por eso los informes llegaron un día después de la 32.1.

CVE-2026-117349, de gravedad media: un peer que afirma no soportar los pings de BIP 31 nunca se desconecta por ignorarlos, y si además lee los mensajes muy despacio, el nodo sigue encolando anuncios de transacciones para él sin límite. La publicación cifra el crecimiento en hasta unos 2 MB por hora para un peer entrante y 5 MB por hora para uno saliente; los nodos que funcionan con blocksonly están mucho menos expuestos. Comunicada el 15 de septiembre y corregida por el pull request #36667, que desconecta a un peer pausado que no ha vaciado su búfer de envío en 20 minutos.

CVE-2026-117350, de gravedad media, afecta solo a Windows, macOS y BSD: el código de sockets basado en select comprobaba condiciones excepcionales incluso con las lecturas pausadas por contrapresión, así que un peer que enviara datos urgentes de TCP podía forzar lecturas que se saltan el límite de memoria por peer hasta dejar el nodo sin memoria. Linux usa poll y no está afectado. Comunicada el 23 de octubre, tres días antes de que se fusionaran las correcciones, y corregida por el pull request #36665.

CVE-2026-117346, de gravedad baja: las posiciones en los archivos de bloques y undo eran de 32 bits, así que cuando un archivo undo superaba los 4 GiB los datos nuevos sobrescribían los antiguos, y una reorganización posterior que necesitara esos datos apagaría el nodo hasta reindexar en una versión corregida. En Windows y en sistemas de 32 bits las escrituras fallan a partir de 2 GiB. La publicación califica la explotación en sistemas de 64 bits de impracticable: un minero necesitaría varios miles de bloques de transacciones no estándar, cerca de un mes de bloques, colocados con precisión, más una reorganización concreta de dos bloques. Comunicada por primera vez el 8 de julio y corregida por el pull request #36669, que guarda las posiciones como enteros de 64 bits sin cambiar el formato en disco; los sistemas de 32 bits siguen afectados.

Las propias notas de release de la 32.1 listan más correcciones que no son CVE: un reintento de la difusión privada (private broadcast) que podía filtrar la IP del remitente al saltarse el proxy de Tor, una vía de ejecución de comandos mediante nombres de wallet manipulados con walletnotify en sistemas que no son Windows, y topes de 10.000 transacciones de difusión privada en cola y 1.000 intentos de envío por cada una. Las notas también dicen que en dos semanas el proyecto divulgará tres vulnerabilidades de gravedad media y alta corregidas en 30.0 (y ninguna de gravedad baja en 32.1), así que toca otra publicación de divulgación hacia el 10 de noviembre.

4. ¿Cómo cambia el nuevo estimador las comisiones que pagas?

Si usas una wallet o un servicio que pide la comisión a un nodo de Bitcoin Core mediante estimatesmartfee, la 32.1 cambia lo que recibe. Hasta ahora Core solo usaba su estimador de política de bloques, que mira hacia atrás las tarifas de las transacciones que se confirmaron dentro de un número objetivo de bloques. Es conservador y tarda en bajar: después de un pico de congestión sigue proponiendo tarifas altas durante un tiempo, porque el historial todavía dice que son altas. La 32.1 añade un estimador de política de mempool que mira lo que está esperando ahora mismo, y estimatesmartfee devuelve el menor de los dos. El estimador de mempool solo puede bajar el resultado, nunca subirlo, así que una wallet basada en Core deja de pagar de más antes cuando los bloques se despejan, y se comporta como siempre cuando la mempool está llena.

La misma idea está detrás de las tarifas que muestran la mayoría de los exploradores. A 2 de noviembre de 2026 mempool.space, que estima solo a partir de la mempool, sitúa el objetivo de media hora en 3 sat/vB, $0.33 para una transferencia típica con un precio de BTC de 77.865 US$:

Tarifas de Bitcoin ahora mismo (mempool.space)

Para los desarrolladores, la RPC gana un objeto de opciones: fee_rate_estimator acepta auto (el valor por defecto, combinado), block_policy (el comportamiento antiguo) o mempool_policy, los valores desconocidos se rechazan, la verbosidad 2 añade mempool_health_statistics y, en modo auto, la respuesta indica qué estimador usó. Los datos de política de bloques se mueven a fees/block_policy_estimates.dat y se migran en el primer arranque. La selección de monedas de la propia wallet usa la estimación combinada. Lo que no cambia: la comisión sigue siendo tu decisión, replace-by-fee y child-pays-for-parent siguen rescatando una transacción que pagó demasiado poco, y los niveles en sat/vB de nuestra guía de comisiones se actualizan cada minuto desde la mempool.

5. ¿Qué cambia para los operadores de nodos?

Actualiza y comprueba en qué rama estás. 29.x llegó a su fin de vida el 27 de octubre de 2026 y la 29.5 del 28 de octubre es su release final, así que un nodo en 29.x no recibirá más correcciones; 30.x sigue mantenida hasta que salga 33.0, 31.x hasta 34.0 y 32.x hasta 35.0. Actualizar desde una versión en fin de vida directamente a 32.1 está soportado, aunque la migración del directorio de datos puede llevar tiempo. Las plataformas soportadas son Linux con kernel 3.17 o posterior, macOS 14 o posterior y Windows 10 versión 1903 o posterior.

Dos valores por defecto cambian tu huella. El valor por defecto de maxconnections sube de 125 a 200, y una nueva opción inboundrelaypercent (50 por defecto) limita la parte de las ranuras entrantes que se da a los peers que retransmiten transacciones; para mantener el comportamiento antiguo, arranca con maxconnections=125 e inboundrelaypercent=100. La retransmisión saliente de transacciones ahora tiene un límite de tasa con una cola global pendiente (txsendrate, 14 transacciones por segundo por defecto, 2,5 veces esa cifra para los peers salientes, más un tope de ancho de banda de 12 MB cada 10 minutos). Los servicios ocultos de Tor creados automáticamente reciben defensas de prueba de trabajo cuando el daemon de Tor las soporta. El servidor RPC ya no usa libevent, y una nueva opción rpcmaxconnections (16 por defecto) limita los clientes HTTP simultáneos.

Dos opciones ahorran disco y tiempo. El índice de transacciones guarda menos datos: un txindex reconstruido ocupa menos de la mitad, pero el ahorro solo se consigue borrando indexes/txindex en el directorio de datos y reiniciando, lo que puede llevar horas; el txospenderindex se reduce de la misma forma. La validación de bloques precarga en paralelo las salidas previas con prevoutfetchthreads, 8 por defecto, 16 como máximo, 0 para desactivarlo. Las sesiones ElGamal antiguas de I2P se eliminarán para la v34 y el soporte de CJDNS está en revisión, así que los operadores que dependan de cualquiera de los dos deberían seguir las próximas notas de release.

6. ¿Qué cambia para los desarrolladores y las wallets?

El cambio que rompe compatibilidad es PSBT versión 2. createpsbt, walletcreatefundedpsbt, converttopsbt y psbtbumpfee producen ahora PSBT de la versión 2 por defecto; un nuevo argumento psbt_version selecciona la versión 0 para las herramientas que aún no pueden interpretar la v2. Si un dispositivo de firma, un coordinador o un script de tu flujo no se ha probado con PSBTv2, pasa el argumento antes de actualizar el nodo con el que habla.

Varios campos y opciones quedan obsoletos: vsize en las RPC de la mempool y en getrawtransaction (usa vsize_adjusted, o vsize_bip141 para el tamaño bruto según BIP 141), la opción de arranque walletrbf y la clave bip125-replaceable (los nodos retransmiten reemplazos de cualquier transacción desde Core 28), y la RPC removeprunedfunds, que ahora necesita deprecatedrpc=removeprunedfunds. Se rechazan los nombres de wallet con elementos de ruta de punto y las wallets cuyo nombre es una barra sola.

Novedades en la superficie RPC: exportwatchonlywallet, addhdkey y derivehdkey; send y sendall dejan de estar marcados como experimentales; getblockchaininfo informa del progreso de la validación en segundo plano de assumeutxo; getbalances añade un saldo nonmempool; getnetworkinfo informa de la versión del asmap; exportasmap y getopenrpcinfo; un comando bitcoin-util getchainparams. El servidor HTTP propio es más estricto con las cabeceras, así que revisa cualquier cliente que envíe cabeceras poco habituales. Nada de esto toca cómo se construye o se difunde una transacción, así que los SDK que hablan con un nodo por RPC estándar, incluido ChainGate, siguen funcionando.

7. ¿Tienen que hacer algo los usuarios de Bitcoin?

No. La 32.1 no cambia ninguna regla de consenso, así que no hay fork, ni moneda nueva, ni nada que migrar; tus claves, direcciones y saldos son los mismos. Si usas una wallet ligera o tienes las monedas en un exchange, la actualización ocurre en las máquinas de otros.

Lo que sí puedes notar es que una wallet conectada a un nodo de Core proponga comisiones más bajas en las horas posteriores a un periodo de congestión, ya que el estimador ahora lee la mempool. Si tienes tu propio nodo, actualiza; si estás en 29.x, estás en una rama sin mantenimiento desde el 27 de octubre. Quien te diga que muevas o "actualices" tus bitcoin por una release de Core está montando una estafa.

8. ¿Qué está confirmado y qué sigue abierto?

9. ¿Qué viene después?

El siguiente punto con fecha es la divulgación de las tres vulnerabilidades corregidas en 30.0, que las notas de release prometen dos semanas después de la release, así que hacia el 10 de noviembre de 2026. La añadiremos aquí, junto con cualquier release de mantenimiento de 32.x. El registro de actualizaciones de abajo recoge qué cambió y cuándo.

Mientras tanto, la guía de comisiones de Bitcoin muestra los niveles en sat/vB en vivo a los que el nuevo estimador se está poniendo al día, la guía sobre el hash de transacción explica cómo seguir una transacción que está esperando, y la noticia sobre el cierre de Binance Pool cubre qué pasa con las transacciones atascadas cuando ese acelerador cierre el 10 de noviembre.

Actualizaciones de este artículo

• 31 de octubre de 2026: primera publicación. Fechas tomadas del issue del calendario de releases de Bitcoin Core, del servidor de descargas de bitcoincore.org y de las páginas de release; detalles de las vulnerabilidades de las tres publicaciones de divulgación del 28 de octubre; contenido de la release de las notas de release de la 32.1 y de la página de ciclo de vida.

Preguntas frecuentes