Bitcoin Core 32.0 llega el 10 de octubre: así compruebas si tu nodo se queda sin mantenimiento

Desde el 14 de septiembre de 2026 existe el primer candidato a publicación de Bitcoin Core 32.0. Para ti, que operas un nodo propio, eso significa dos cosas: el alcance funcional de la próxima versión principal ya está cerrado, y con su aparición la serie 29 sale de la ventana de mantenimiento del proyecto. Quien siga hoy en 29.x no recibirá más correcciones de seguridad después de la fecha prevista del 10 de octubre. La comprobación dura dos minutos; la actualización cuesta media hora según la instalación.

Un recuento propio de los nodos accesibles en todo el mundo, que hemos realizado para este artículo la mañana del 15 de septiembre, muestra el tamaño del grupo afectado: alrededor de seis de cada diez nodos de Bitcoin accesibles funcionan con una versión que dejará de estar mantenida en cuanto aparezca la 32.0. Las cifras y el método están más abajo.

Bitcoin Core 32.0: qué ocurrió el 14 de septiembre

Bitcoin Core es el software de referencia de la red Bitcoin. Comprueba bloques y transacciones contra las reglas de consenso, mantiene una copia propia de la cadena de bloques y es, por tanto, la base para cualquiera que no deje sus pagos en manos de una infraestructura ajena. Según su propio calendario, el proyecto publica una versión principal cada seis meses aproximadamente.

El 14 de septiembre de 2026 apareció en el repositorio de código del proyecto la etiqueta v32.0rc1, es decir, el primer candidato a publicación de la próxima versión principal. El medio sectorial TFTC indica las 12:58 UTC y da el 10 de octubre de 2026 como fecha prevista para la etiqueta definitiva. Entre el candidato y la publicación media, por tanto, una ventana de pruebas de unas cuatro semanas. A modo de comparación: la última versión principal publicada, la 31.0, es del 19 de abril de 2026 según el plan de ciclo de vida del proyecto, y la versión de mantenimiento correspondiente, la 31.1, lleva en el directorio de descargas la fecha del 7 de julio de 2026.

Un candidato a publicación no es una prueba previa en el sentido de una beta. El código se considera funcionalmente completo. Lo que todavía entra son exclusivamente correcciones de fallos detectados durante la ventana de pruebas. Para ti como operador eso significa que el contenido de la próxima versión ya se conoce y que puedes contrastar tu configuración con él desde ahora, en lugar de llevarte una sorpresa el día de la publicación.

Candidato, congelación de funciones y ventana de mantenimiento: tres conceptos para este artículo

Candidato a publicación

Un candidato a publicación es una versión que el proyecto considera lista para salir y somete a pruebas amplias antes de la publicación definitiva. Lleva el añadido rc1, rc2 y así sucesivamente, y se retira o se sustituye si aparece un fallo grave.

Congelación de funciones

La congelación de funciones es el momento a partir del cual no se incorporan funciones nuevas a una versión. Es anterior al primer candidato a publicación y explica que el alcance funcional de la 32.0 ya pueda describirse.

Ventana de mantenimiento

La ventana de mantenimiento es el periodo en el que una versión principal todavía recibe correcciones de fallos y de seguridad. Según su propio plan de ciclo de vida, Bitcoin Core mantiene siempre las tres versiones principales más recientes. En cuanto aparece una versión principal nueva, la más antigua de esas tres se cae de la lista y pasa a fin de vida. Las versiones en estado de fin de vida, por regla general, tampoco reciben ya correcciones de seguridad.

Recuento propio: el 60 % de los nodos accesibles pierde el mantenimiento con la 32.0

Este análisis lo realizó cryptoticker.io el 15 de septiembre de 2026. El método en una frase: a las 06:35 UTC descargamos la instantánea pública del contador de nodos btcnodes.io (antes bitnodes.io) y contamos por versiones principales el identificador de versión que cada nodo declara de sí mismo.

Se examinaron 26.516 nodos de esa instantánea. De ellos, 25.902 llevan un identificador con la forma habitual y número de versión; los 614 restantes declaran otro software, y 556 de ellos una implementación en forma de biblioteca sin relación de versión con Bitcoin Core. El recuento se refiere a esos 25.902 nodos.

• 29.x: 8.629 nodos (33,31 %), justo la serie que sale del mantenimiento con la aparición de la 32.0.
• 28.x y anteriores: 7.017 nodos (27,09 %), ya hoy sin mantenimiento. La serie 28 está en fin de vida desde el 19 de abril de 2026.
• 30.x: 1.732 nodos (6,69 %) y 31.x: 8.512 nodos (32,86 %), las dos series que seguirán mantenidas junto a la 32.x tras la publicación.
• 32.x: 12 nodos (0,05 %), previsiblemente sistemas de prueba que ya ejecutan el candidato.

Si se suman la serie 29 y todo lo anterior, salen 15.646 nodos, es decir, el 60,40 %. Esa mayoría se queda sin software mantenido al día siguiente de la publicación. Hallazgo colateral del mismo recuento: 4.459 nodos (17,2 %) declaran además el identificador de la implementación divergente Bitcoin Knots, que tiene su propio ritmo de publicación y no se ve afectada por este plan de mantenimiento.

Lo que este estudio no puede hacer también forma parte de él. La instantánea no contiene ningún campo de país, así que de ahí no se puede deducir una cifra separada por países. El identificador de versión es una declaración propia y técnicamente falsificable. Y se cuentan únicamente los nodos accesibles desde fuera. Quien opera su nodo tras un cortafuegos o lo hace accesible solo a través de Tor no aparece en esta estadística. La cifra real de instalaciones obsoletas será, por tanto, probablemente más alta que la indicada aquí.

Ventana de mantenimiento de Bitcoin Core: qué versión se cae y cuándo

El plan de ciclo de vida del proyecto es una tabla pública y se puede leer línea a línea. Las entradas que te importan:

• 29.x, aparecida el 14 de abril de 2025: fin de vida con la aparición de la 32.0, es decir, según la previsión actual, el 10 de octubre de 2026.
• 30.x, aparecida el 10 de octubre de 2025: fin de vida solo con la 33.0.
• 31.x, aparecida el 19 de abril de 2026: fin de vida solo con la 34.0.
• 28.x: en fin de vida desde el 19 de abril de 2026.

El proyecto recomienda expresamente ejecutar la versión de mantenimiento más reciente de la versión principal más alta a la que uno pueda cambiar. Hay aquí una particularidad que respalda una ruta de actualización tranquila: el proyecto entrega las propuestas de cambio en las reglas de consenso primero en las versiones de mantenimiento, no en las principales. Quien actualiza de forma conservadora sigue así siendo compatible, mientras su propia versión principal esté mantenida. Justo esa compatibilidad se acaba en octubre para la serie 29.

Leer la versión de Core: así averiguas con qué funciona tu nodo

Antes de descargar nada, determina dónde estás. Tres vías, según la instalación.

Línea de órdenes

En un servidor o en un ordenador de placa única, bitcoind --version da el número de versión directamente en la primera línea. Con el servicio en marcha también sirve bitcoin-cli --version o, si ya estás hablando con el nodo, la llamada bitcoin-cli getnetworkinfo; allí el identificador está en el campo subversion, con la misma forma que ha empleado nuestro recuento de arriba.

Interfaz gráfica

En la aplicación de escritorio encuentras el número de versión en la entrada de menú Ayuda, en la ventana con la información sobre la aplicación. También figura en la ventana de información de depuración, que la aplicación ofrece bajo la entrada de menú Ventana.

Paquete de nodo preconfigurado

Quien opera una solución llave en mano, es decir, un sistema operativo preconfigurado para el nodo doméstico, lee por lo general la versión de Core en la vista de detalle de la aplicación correspondiente. Aquí lo que importa es la versión de Bitcoin Core en sí, no el número de versión de la interfaz que lo rodea. Las dos cifras casi siempre difieren, y solo la primera decide sobre el mantenimiento.

Apunta el número. Si pone 29 o algo menor, tienes una tarea para las próximas semanas. Si pone 30 o 31, de momento estás del lado seguro y puedes planificar la actualización con calma.

Qué cambia en Bitcoin Core 32.0: estimación de comisiones, índice e interfaz

El borrador de las notas de publicación de la 32.0 está en el wiki de desarrollo del proyecto. Es expresamente un borrador y puede cambiar todavía hasta la etiqueta definitiva; los puntos siguientes hay que leerlos, por tanto, como una orientación y no como una redacción final.

Llama la atención el énfasis en la operación y no en funciones visibles. La estimación de comisiones combinará en adelante el estimador basado en bloques con el estimador del mempool, y resulta así más prudente. Según el borrador, el índice de transacciones ocupa menos de la mitad del espacio de disco anterior, aunque solo tras una reconstrucción del índice. La validación de bloques suma una precarga paralela de los datos de entrada con un ajuste propio para el número de hilos de trabajo, fijado por defecto en ocho y limitado a dieciséis.

En la capa de red, el borrador recoge una limitación global, y ya no por conexión, del reenvío de transacciones, además de una protección por prueba para los servicios Tor allí donde la contraparte lo admita. El cifrado obsoleto de la red I2P llega a su fin; quien opere su nodo a través de ella debería planificar el cambio antes de la versión 34. La interfaz recibe nuevas llamadas para el manejo de claves y para exportar una cartera de solo lectura, y el servidor HTTP integrado se ha reescrito, junto con un nuevo límite de conexiones simultáneas.

Nada de esto te obliga a actuar el día de la publicación. Aun así, conviene anotar dos puntos: la reconstrucción del índice, si el espacio de disco se te queda corto, y los ajustes eliminados, de los que trata el siguiente apartado.

Opciones eliminadas en bitcoin.conf: por qué tu nodo avisa tras la actualización

El disgusto más habitual tras un salto de versión principal no viene del programa, sino del propio archivo de configuración. Según el borrador, en la 32.0 desaparecen varios ajustes que durante años estuvieron en los tutoriales. Entre ellos, un ajuste sobre la sustituibilidad completa de transacciones en el mempool y una opción de red más antigua. Además desaparecen dos claves de las respuestas de las llamadas al mempool, salvo que las vuelvas a activar expresamente mediante el ajuste para interfaces obsoletas.

En la práctica eso significa: abre tu bitcoin.conf antes de actualizar y coteja cada línea con las notas de publicación. Un nodo que no arranca por un ajuste desconocido, o que se levanta con avisos, es una noche en vela innecesaria. Quien haya colgado de la interfaz scripts propios o un programa de contabilidad debe comprobar además si allí se lee alguna de las claves que desaparecen.

Probar el candidato sin poner en riesgo el nodo de producción

Cuatro semanas de ventana de pruebas son una invitación, y vale también para operadores sin formación de desarrollador. Cuantas más instalaciones distintas ejecuten el candidato, antes saldrán a la luz los fallos antes de acabar en la versión publicada. Tres reglas hacen que probar no entrañe peligro.

Primera: un candidato a publicación no pinta nada en el nodo del que cuelga tu cartera. Un aparato separado, una máquina virtual o el funcionamiento de prueba en la red de pruebas bastan de sobra. Segunda: antes de arrancar compruebas la firma de los archivos descargados contra las sumas de comprobación publicadas; eso es tan obligatorio en una versión previa como en una publicación normal. Tercera: comunicas cualquier comportamiento llamativo mientras la ventana siga abierta. Después de la etiqueta definitiva, el camino de las correcciones es bastante más largo.

Quien quiera ir sobre seguro hace antes de cada salto de versión una copia del archivo de la cartera y del archivo de configuración, y la guarda separada del nodo. Eso vale para el candidato igual que para la publicación posterior. Con qué rigor se aplica esa misma disciplina a los aparatos de hardware quedó claro este año en el caso de un fabricante cuyo fallo de firmware afectó a toda una generación de aparatos.

¿Sin nodo propio? Qué dice esta actualización sobre tu custodia

La mayor parte de quienes leen esto no opera un nodo propio, y es una decisión legítima. Aun así, esta publicación tiene algo que decirte. Quien deja sus fondos en un exchange o en un bróker confía en que allí alguien tenga a la vista esta ventana de mantenimiento. Quien custodia por sí mismo pero accede a un servidor ajeno mediante una aplicación de cartera confía en ese mismo tercero desconocido, solo que un nivel más abajo.

La vía intermedia práctica para la mayoría es separar las claves del software: las claves están en un aparato que nunca se conecta a la red y el software sigue siendo intercambiable. Qué aparatos entran en consideración y en qué se diferencian está en nuestra comparativa de carteras de hardware. El nodo propio llega después como segundo paso, y la cuestión de la versión de este artículo pasa entonces a ser también tuya.

Que el mantenimiento no es un asunto marginal lo muestran dos casos de las últimas semanas: una vulnerabilidad en una implementación de Lightning y un agujero crítico en una interfaz de cartera muy extendida, donde solo la accesibilidad desde internet decidía el riesgo. En ambos casos el remedio era una actualización que ya estaba disponible.

Lo que esta publicación no es: ni cambio de consenso ni acontecimiento de mercado

Una aclaración frente a las conclusiones erróneas más evidentes. Según el borrador disponible, Bitcoin Core 32.0 no modifica ninguna regla de consenso. No hay votación, ni plazo de señalización, ni momento alguno en el que un nodo sin actualizar se caiga de la red. Un nodo con la versión 29 seguirá validando correctamente después del 10 de octubre. Lo que le faltará son las correcciones de los fallos que se encuentren a partir de entonces.

Tampoco una publicación es un acontecimiento de mercado. Quien establece una conexión entre números de versión y movimientos de precio afirma algo que no se puede demostrar. La relevancia de esta fecha está únicamente en la operación: en la pregunta de si el software que comprueba tus pagos sigue estando mantenido.

Queda la cuestión del momento adecuado. Saltar a la 32.0 el día de la publicación no es un error para un nodo privado, pero tampoco una obligación. Quien va en 30.x o 31.x tiene meses por delante. Quien está en 29.x o por debajo debería planificar el cambio en octubre, y concretamente a la versión de mantenimiento más reciente de la versión principal más alta que permita su instalación. Para instalaciones en las que un nodo completo exige demasiado espacio de disco, el modo podado sigue siendo una opción; el trabajo de validación el nodo lo hace igual.

Comprobar Bitcoin Core 32: lo que te llevas de aquí

1. Lee la versión y anótala. Con bitcoind --version, en la ventana de información de la aplicación de escritorio o en la vista de detalle de tu solución llave en mano. Si pone 29 o menos, ponte una fecha en octubre. Quien todavía no custodia por sí mismo debe aclarar primero la cuestión de las claves y mirar para ello la comparativa de carteras de hardware.
2. Prepara el archivo de configuración y la copia de seguridad. Cotejar cada línea de tu bitcoin.conf con las notas de publicación y guardar por separado el archivo de la cartera y la configuración. Quien mantenga sus claves en una aplicación del ordenador debe comprobar en paralelo su estado de actualización con nuestra comparativa de carteras de software.
3. Prueba en un aparato separado y cambia después con calma. No ejecutes nunca el candidato en el nodo del que cuelga tu cartera. Y si compruebas que no quieres operar ningún nodo propio, entonces la elección del proveedor que custodia es la decisión que cuenta aquí, y para eso merece la pena mirar la comparativa de exchanges.

Las fuentes de este artículo: el plan de ciclo de vida de Bitcoin Core con la tabla de mantenimiento y la lista de etiquetas del repositorio de código, donde figura el candidato v32.0rc1 con su fecha.

(15 de septiembre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)