Bitcoin Core 32 llega con validación 3x más rápida aunque 60% de nodos quedan atrás
Patricia López · Bitcoin · 2026-09-16
La primera versión candidata entró en pruebas el sábado con mejoras de rendimiento y una corrección de seguridad crítica. Release objetivo: 10 de octubre. Pero seis de cada diez nodos de la red perderán soporte cuando se lance.
La primera versión candidata de Bitcoin Core 32.0 (v32.0rc1) se etiquetó el lunes 14 de septiembre a las 12:58 UTC y entró en fase de pruebas comunitarias. El objetivo de lanzamiento definitivo es el 10 de octubre. La mejora más notoria: los nodos podrán validar bloques hasta tres veces más rápido en ciertos entornos gracias al procesamiento paralelo de datos de transacciones anteriores (prevouts), aprovechando mejor las CPUs con múltiples núcleos.
La fase de candidato a lanzamiento (<abbr title="Release Candidate: versión beta final que se prueba antes del lanzamiento oficial">RC</abbr>) es el último filtro antes de que una versión mayor de Bitcoin Core se considere estable. Durante estas semanas, operadores de nodos, exchanges y desarrolladores ejecutan la versión en entornos de prueba y producción buscando regresiones o comportamientos inesperados. Si no aparecen problemas críticos, la RC1 se convierte en release final; si los hay, se publica RC2 y sucesivas hasta que la versión sea segura.
Tres mejoras operacionales concretas
Además del salto de velocidad en validación de bloques, Core 32 introduce dos cambios que afectan directamente a quienes operan nodos y envían transacciones. El primero: un segundo estimador de comisiones que examina transacciones en espera de confirmación en la mempool, además del método tradicional basado en bloques pasados. El software compara ambos y recomienda las comisiones más bajas cuando las condiciones de red lo permiten, lo que puede reducir el coste de envío en momentos de baja congestión.
El segundo cambio reemplaza el modelo anterior de limitación de tasa por par con un sistema global. Hasta ahora cada conexión de nodo gestionaba sus propios límites de tasa de transacciones; ahora el límite es global a nivel de nodo. El objetivo: hacer los nodos más resilientes durante ráfagas súbitas de actividad de red, como ocurrió en episodios recientes de spam en mempool o lanzamientos de tokens experimentales sobre Bitcoin.
Corrección de seguridad crítica para sistemas no-Windows
La versión incluye la corrección de una vulnerabilidad presente en Bitcoin Core desde la versión 24.0 que afectaba a sistemas operativos distintos de Windows. Usuarios autenticados con permisos de creación de wallet podrían ejecutar comandos en condiciones específicas mediante nombres de wallet especialmente elaborados, pero solo si la característica walletnotify estaba habilitada. La corrección se fusionó en el repositorio el 2 de septiembre.
Este tipo de vulnerabilidad requiere acceso autenticado y configuración específica, por lo que el vector de ataque es limitado. Aun así, los operadores de nodos con walletnotify activo en entornos Linux o macOS deberían priorizar la actualización una vez que la versión final esté disponible.
Seis de cada diez nodos perderán soporte en octubre
Bitcoin Core mantiene en soporte las tres versiones mayores más recientes. Cuando aparece una nueva versión mayor, la más antigua de esas tres pierde mantenimiento oficial y deja de recibir correcciones de seguridad. Según conteo del 15 de septiembre, aproximadamente el 60% de los nodos Bitcoin alcanzables en la red ejecutan versiones que entrarán en fin de vida una vez que se lance Core 32.0 el 10 de octubre.
Las versiones mayores de Bitcoin Core se lanzan cada 6 a 8 meses. El calendario actual coloca a Core 32 en el turno de otoño de 2026; el desarrollo de la versión 33 ya avanzó en la rama master tras la congelación de características del 20 de agosto. La separación de la rama de lanzamiento 32.x el 14 de septiembre permite que ambas líneas evolucionen en paralelo: bugfixes para la 32, nuevas características para la 33.
- Validación paralela de prevouts: hasta 3x más rápido en CPUs multicores, especialmente útil para nodos con hardware modesto que procesan bloques completos.
- Estimador dual de comisiones: compara datos históricos con mempool actual para recomendar fees más ajustadas cuando la red está tranquila.
- Rate limiting global: protección más robusta contra ráfagas de transacciones que pueden saturar nodos individuales.
- Corrección de seguridad: cierra vector de ejecución de comandos en Linux/macOS con walletnotify habilitado, presente desde Core 24.0.
La firma GPG de la etiqueta RC1 está verificada y lleva el identificador de clave 9B79B45691DB4173, asociada al desarrollador conocido como «sedited» con la etiqueta Reproducibility Matters. El commit específico es d0231bb.
Qué sigue hasta el 10 de octubre
El período de RC suele durar entre dos y cuatro semanas. Durante ese tiempo, la comunidad técnica somete la versión a estrés: sincronización completa desde genesis, escenarios de alta carga de mempool, pruebas de <abbr title="Application Programming Interface: interfaz para comunicarse con el software">API</abbr> RPC con aplicaciones de terceros. Si aparece algún bug crítico o regresión de funcionalidad, se publica una nueva RC con la corrección. Una vez que la versión supera el período sin incidencias graves, se retira la etiqueta RC y se libera como versión estable.
Los operadores de nodos que ejecutan versiones antiguas tienen menos de un mes para planificar la actualización si quieren seguir recibiendo parches de seguridad. El proceso de actualización en sí es sencillo — descargar binarios verificados, detener el nodo, sustituir ejecutables, reiniciar — pero en entornos de producción con servicios críticos (exchanges, procesadores de pago, aplicaciones Lightning) requiere coordinación y ventana de mantenimiento. Por eso el aviso del 60% de nodos fuera de soporte importa: no es solo estadística, es riesgo operacional para una parte mayoritaria de la infraestructura de la red.