Bitcoin Core 32.0: qué cambia en tu nodo, qué no hay que tocar y qué pasa si no actualizas
Bitcoin Core 32.0 es una versión mayor sin ningún cambio de consenso: no obliga a actualizar, no exige reindexar ni migrar la wallet, y lo único que caduca con su publicación es el soporte de la serie 29.x. Lo que sí cambia para un nodo doméstico son las conexiones por defecto, la velocidad de sincronización, el servidor RPC y la estimación de comisiones.
Actualización, 23 de octubre de 2026: hemos añadido dos avisos. La interfaz gráfica de 32.0 genera transacciones que las versiones anteriores de Core no saben abrir, y eso puede atascar una multifirma con nodos de versiones distintas; el aviso está justo antes del checklist. Y Core ha cambiado su política de divulgación de vulnerabilidades, lo que da un motivo más para no retrasar las actualizaciones; lo explicamos al final, en el apartado sobre qué pasa si no actualizas.
Los mantenedores de Bitcoin Core etiquetaron la versión 32.0 el 21 de octubre de 2026, once días después del objetivo que se habían marcado, y su salida es, en la práctica, el momento en que la serie 29.x deja de recibir parches de seguridad. Ese es el único efecto sobre quien no haga nada; todo lo demás solo afecta a quien decida instalarla. Este artículo se escribió el 11 de septiembre de 2026, se revisó el 13 de octubre contra la cuarta release candidate y se ha cotejado el 22 de octubre con las notas finales de la versión [1], las que acompañan al tag: cada afirmación va fechada.
Tres hitos cumplidos, el último con once días de retraso
El calendario vive en la issue #35122 del repositorio [2], abierta por el mantenedor fanquake el 20 de abril de 2026: feature freeze el 20 de agosto, rama 32.x y primera release candidate, previstas al principio para el 10 de septiembre, y tag v32.0 el 10 de octubre, marcado literalmente como "aim", un objetivo y no una promesa.
La rama 32.x se separó y v32.0rc1 se etiquetó el 14 de septiembre, cuatro días después de la fecha prevista; le siguieron rc2 el 18 de septiembre, rc3 el 1 de octubre y rc4 el 12 de octubre, con binarios de prueba en bitcoincore.org. El 10 de octubre pasó sin versión final, y el tag v32.0 [3] llegó el 21 de octubre de 2026, firmado por sedited a las 15:27, hora peninsular. No cambia código respecto a rc4: entre las dos solo cambian el número de versión, las páginas del manual y las notas. A 22 de octubre de 2026 aún no había binarios finales ni página de la versión en bitcoincore.org, así que la descarga oficial todavía no estaba disponible.
Más conexiones y sincronización más rápida
Dos cambios tocan a cualquier nodo, con o sin wallet. El primero figura en las notas finales: el límite máximo de pares pasa de 125 a 200 (PR #28463, fusionada el 24 de julio dentro del hito 32.0). El motivo declarado es reservar más capacidad de entrada para conexiones que solo retransmiten bloques, y una opción nueva, -inboundrelaypercent, limita por defecto al 50 % de las plazas de entrada los pares que retransmiten transacciones. Para quien tiene el puerto 8333 abierto son hasta 75 pares más entrando, con sus descriptores de fichero, memoria y ancho de banda; -maxconnections sigue ahí para fijarlo donde tu máquina aguante, y las notas indican que -maxconnections=125 -inboundrelaypercent=100 devuelve los límites anteriores. Si ya lo tenías fijado, tu valor se respeta, pero el nuevo tope para los pares que retransmiten transacciones se aplica igual.
El segundo también está en las notas. Al conectar un bloque, cada entrada gastada exige leer del disco la moneda que gasta, y hasta ahora esas lecturas iban una a una. La PR #35295 las mueve a un grupo de hilos que precargan la caché en paralelo, con la opción -prevoutfetchthreads (8 por defecto, máximo 16, 0 para desactivar). Las notas finales dicen solo que acelera la validación cuando esas monedas hay que leerlas del disco, sin dar un multiplicador; la ganancia depende de cuánto de tu conjunto de monedas cabe en dbcache. La cifra de "hasta tres veces más rápido" que circula en prensa no está en las notas.
Servidor RPC nuevo y límite global de retransmisión
El servidor que atiende RPC y REST se ha reescrito desde cero y ya no depende de libevent (PR #35182). Trae una opción nueva, -rpcmaxconnections, con 16 clientes simultáneos por defecto. Si sobre tu nodo cuelgan varias aplicaciones que hablan RPC a la vez (un explorador de mempool propio, un servidor Electrum, un nodo Lightning), es el ajuste a revisar antes que ningún otro. En sentido contrario, las notas aconsejan bajarlo en máquinas con pocos recursos, porque el nodo reserva descriptores de fichero para esas conexiones. Un cliente desde una IP no permitida por -rpcallowip ahora se desconecta sin más, en vez de recibir un 403.
El ritmo al que un nodo reenvía transacciones a sus pares se limitaba por par; ahora hay un único contador global (PR #34628), con el mismo tope de 14 transacciones por segundo, un límite adicional de 12 MB cada 10 minutos y la opción -txsendrate, para gastar menos memoria y CPU en picos de volumen.
Piezas menores en la misma dirección: los servicios onion que el nodo crea solos activan las defensas de prueba de trabajo de Tor si el demonio las soporta (#33414); los bits 5 a 28 de la versión de bloque dejan de generar avisos según BIP 323 (#34779); el proyecto estudia retirar CJDNS (#36202). Y se corrige una posible fuga de la IP de quien envía una transacción con -privatebroadcast=1: si fallaba la conexión con el protocolo v2, el reintento con v1 podía salir directo en vez de por Tor (#35410).
Lo que solo notarán quienes usan la wallet o la API
El nuevo estimador de comisiones es el cambio con más superficie. estimatesmartfee combina el estimador clásico basado en bloques con otro basado en el mempool y devuelve el menor de los dos (PR #34075): el mempool solo puede rebajar la recomendación, porque el estimador clásico no se manipula inflando el mempool y el nuevo sí podría. El de mempool solo da cifra cuando los bloques recientes indican un mempool sano; si no puede darla, por ejemplo justo después de arrancar, la llamada devuelve la del estimador clásico, y solo da error cuando tampoco el clásico tiene datos, igual que antes. Con un mempool demasiado vacío no se calla: recomienda el mínimo para que la transacción se retransmita, el mayor entre la comisión mínima de retransmisión y la mínima actual del mempool. Así lo describen las notas finales y la ayuda del RPC; un borrador anterior de las notas avisaba de un error durante el calentamiento que ya no aplica. Además, estimatesmartfee acepta la opción fee_rate_estimator para pedir solo el estimador clásico (block_policy) o solo el de mempool (mempool_policy).
En la wallet, createpsbt, walletcreatefundedpsbt, converttopsbt y psbtbumpfee generan PSBT versión 2 (BIP 370) por defecto, con un argumento psbt_version para pedir la 0 si tu firmador externo no entiende la nueva. Llega exportwatchonlywallet, que exporta una copia sin claves privadas de una wallet de descriptores para vigilarla desde un nodo conectado, y dos RPC nuevas de claves HD: addhdkey, que añade una clave extendida BIP 32 a la wallet, y derivehdkey, pensada para coordinar multifirmas. Se cierra un fallo de seguridad real: un nombre de wallet con caracteres especiales podía ejecutar comandos vía -walletnotify en sistemas distintos de Windows (#36048). Y lo que no llega: Silent Payments (BIP 352) no está en 32.0: la PR de su protocolo base (#35301 [4]) se fusionó el 23 de septiembre, con la rama de 32.0 ya separada, y las de envío y recepción siguen abiertas a 22 de octubre, pese a que la cobertura en español lo ha dado por incluido.
Aviso: la interfaz gráfica de 32.0 puede atascar una multifirma
Las notas finales no lo mencionan, pero afecta a cualquiera que firme en grupo. La interfaz gráfica de 32.0 crea las PSBT, las transacciones parcialmente firmadas, en versión 2 y sin ninguna opción para elegir otra, y una versión de Core anterior a la 32 no sabe importarlas: se queda en un error de versión no soportada, según la incidencia abierta en el repositorio [7]. El código de la 31.1 lo confirma, porque solo acepta la versión 0. Si en una multifirma un cofirmante ya actualizado prepara el gasto desde la interfaz y otro sigue con 31.x o anterior, ese segundo no puede abrir el fichero y la firma no avanza. Es un problema de compatibilidad, no de seguridad: los fondos siguen donde estaban.
El mantenedor fanquake lo pasó al hito de la 32.1 el 21 de octubre, porque la 32.0 ya iba con retraso y aún no había nada listo para portar. La corrección propuesta, la PR #36539 [8], devuelve la interfaz a la versión 0 y seguía abierta cuando la comprobamos el 23 de octubre, igual que la vio CryptoSlate [9] el día anterior. Mientras no salga la 32.1, si coordinas una multifirma con versiones mezcladas, crea la transacción por RPC con psbt_version=0 (lo aceptan walletcreatefundedpsbt y createpsbt), o espera a que todos los firmantes estén en 32.0.
Checklist: siete pasos, en este orden
- Espera a los binarios finales, no a la rc. El tag ya existe, pero lo que se instala son los binarios publicados en bitcoincore.org. Las release candidates existen para quien quiera cazar fallos; un nodo que sostiene fondos o servicios no es el sitio.
- Verifica firmas antes de instalar. Binario,
SHA256SUMSy su.ascdesde bitcoincore.org; comprueba hash y firma con las claves de los desarrolladores publicadas en el repositorio. - Para el nodo y espera a que cierre del todo. Es el procedimiento oficial literal: parar, esperar (minutos si
dbcachees grande), sustituir los binarios, arrancar. - Si tienes el puerto abierto, decide tu límite de conexiones. O aceptas los 200 pares por defecto con su tráfico entrante, o fijas
-maxconnections. - Si varias aplicaciones usan tu RPC, revisa
-rpcmaxconnections. Con 16 por defecto, explorador más servidor Electrum más Lightning puede quedarse corto en picos. - Si algo firma con tu wallet, prueba las PSBT. Un firmador sin soporte de versión 2, o un cofirmante con un Core anterior a la 32, necesita
psbt_version: 0, o fallará sin explicación clara. Desde la interfaz gráfica no se puede elegir. - Tras arrancar, comprueba altura y pares con
getblockchaininfoygetnetworkinfo.
Solo el tercero es obligatorio. El resto depende de lo que tengas enchufado al nodo.
Qué no hace falta hacer
No hace falta mover fondos ni tocar semillas: una versión mayor no altera tus claves ni la validez de tus transacciones. No hace falta migrar la wallet: las notas finales no mencionan ninguna migración de formato ni de base de datos, y el texto oficial de actualización sigue diciendo que las wallets antiguas están soportadas en general. Solo avisa de que, si vienes de una versión ya en fin de vida, el arranque puede tardar si hay que migrar el directorio de datos. No hace falta reindexar: nada en 32.0 exige -reindex ni -reindex-chainstate. El fichero de estimación de comisiones se mueve solo a fees/block_policy_estimates.dat al primer arranque.
Eso sí, hay una opción que parece obligatoria y no lo es. El índice de transacciones (-txindex) pasa a ocupar menos de la mitad, pero solo si lo reconstruyes borrando indexes/txindex y dejando que el nodo lo regenere durante horas; el viejo sigue funcionando tal cual. Y ojo con la vuelta atrás: un índice ya reconstruido no lo lee una versión anterior, que lo vuelve a construir en el formato viejo; si bajas de versión para quedarte, bórralo antes, porque la versión anterior no libera el espacio de las entradas nuevas. El de gastadores (-txospenderindex) también adelgaza: el índice existente sigue siendo compatible y no hay que hacer nada, salvo reconstruirlo si quieres recuperar el espacio de lo indexado antes de actualizar.
Si no actualizas: qué te pasa y cuándo caduca tu versión
Nada, en lo que respecta a la cadena. Un nodo con 31.1, 30.3 o 29.4 valida exactamente los mismos bloques que uno con 32.0, porque no hay cambio de consenso, y ningún par te rechaza por la versión que anuncias.
Lo que caduca es el mantenimiento. La política de ciclo de vida [5] del proyecto mantiene las tres últimas versiones mayores y declara "fin de vida" a la más antigua cuando sale una nueva, sin parches de seguridad a partir de ahí; son unos 18 meses de soporte por serie según la tabla de endoflife.date [6]. Aplicado a 32.0:
| Serie | Última versión | Estado tras la salida de 32.0 |
|---|---|---|
| 31.x | 31.1 (8 de julio de 2026) | Mantenida hasta que salga 33.0 |
| 30.x | 30.3 (10 de julio de 2026) | Mantenida hasta que salga 33.0 |
| 29.x | 29.4 (10 de julio de 2026) | Fin de vida: sin más parches |
La lectura práctica: quien corre 30.x o 31.x puede saltarse esta versión sin coste hasta que llegue 33.0, previsiblemente en la primavera de 2027 si se mantiene la cadencia. Quien sigue en 29.x sí tiene fecha: con la salida de 32.0 su serie deja de recibir correcciones, y las notas finales anuncian que dos semanas después se publicarán las vulnerabilidades de severidad media y alta corregidas en la 30.0, que son tres. Es el único plazo de esta versión que no admite esperar.
Desde el 22 de octubre hay un motivo más para no dejar pasar meses entre un parche y su instalación. Ese día Antoine Poinsot anunció en la lista de correo de desarrollo de Bitcoin [10] que Core cambia su política de divulgación, porque los modelos de lenguaje han abaratado mucho encontrar cierto tipo de fallos o detectar correcciones discretas. Cuando un fallo se considere fácil de descubrir, por ejemplo con una simple consulta a un modelo de lenguaje, el proyecto publicará cuanto antes una versión de corrección para cada serie mayor mantenida, con un aviso de seguridad y sin el embargo habitual. El resto sigue los plazos de siempre, según la política publicada en bitcoincore.org [11]: los de severidad baja se publican dos semanas después de la versión mayor que los corrige, los de severidad media y alta dos semanas después de que la última versión afectada llegue a fin de vida, y los críticos se tratan aparte. Esa segunda regla es la que pone fecha a la 29.x.
Para quien tiene un nodo, la consecuencia es sencilla. Cuando salga una versión de corrección con aviso de seguridad, parte de los detalles ya serán públicos ese mismo día, así que conviene instalarla en días, no en meses. Y una serie en fin de vida, como la 29.x tras la salida de 32.0, no recibirá esas correcciones. Lo ha recogido también Cointelegraph [12].
Fuentes
Entre paréntesis, el tipo de fuente.
- Bitcoin Core, notas finales de la versión. (Primaria, repositorio oficial)
- Bitcoin Core, issue #35122 del repositorio. (Primaria, repositorio oficial)
- Bitcoin Core, tag
v32.0. (Primaria, repositorio oficial) - Bitcoin Core, #35301. (Primaria, repositorio oficial)
- Bitcoin Core, política de ciclo de vida. (Primaria, web oficial del proyecto)
- endoflife.date, endoflife.date. (Secundaria, agregador)
- Bitcoin Core, issue #36518 del repositorio. (Primaria, repositorio oficial)
- Bitcoin Core, PR #36539. (Primaria, repositorio oficial)
- CryptoSlate, Bitcoin Core 32 can stall multisig signing on older nodes as fix slips to next patch. (Secundaria, medio especializado)
- Antoine Poinsot, «Bitcoin Core security policy update», lista bitcoindev. (Primaria, lista de correo de desarrollo)
- Bitcoin Core, política de seguridad y avisos. (Primaria, web oficial del proyecto)
- Cointelegraph, Bitcoin Core changes security policy as AI makes bugs easier to find. (Secundaria, medio especializado)
- NodeWitness, datos propios, consultables en Red y minería. (Primaria, dato propio)
Nuestro nodo, un Bitcoin Core completo y sin pruning, estaba en el bloque 972.584 el 22 de octubre de 2026 a las 07:34 UTC cuando se revisó esto. Puedes comparar en cualquier momento su altura en vivo y su estado de sincronización con la del resto de la red en Red y minería, sin tener que fiarte de la fecha de este artículo.
Más en Red y minería
Última actualización: 23 de octubre de 2026