La rama 32.x de Bitcoin Core avanza al tercer candidato de lanzamiento
Publicación de la fuente: 2026-10-01 · Análisis editorial publicado: 2026-10-02
El cambio a rc3 y la documentación regenerada se fusionaron el 1 de octubre tras 29 commits desde rc2. Los operadores deben esperar binarios oficiales firmados y tratar el candidato como software de prueba.
Análisis e implicaciones prácticas
Esta sección contiene nuestro análisis y cálculos ilustrativos, separados del informe original.
La rama 32.x ahora se identifica como rc3
Los mantenedores de Bitcoin Core fusionaron la solicitud de extracción 36400 el 1 de octubre, avanzando la rama 32.x a la versión 32.0rc3. La solicitud de extracción en sí contiene tres confirmaciones: el aumento de versión, páginas de manual regeneradas y un ejemplo bitcoin.conf regenerado. Cambió nueve archivos y se fusionó como confirmación 2633a1de. Este es un hito en la preparación del lanzamiento en el control de fuente, no un anuncio de que la versión final de Bitcoin Core 32.0 está disponible.
Se crea una versión candidata para realizar pruebas
La documentación del ciclo de vida de Bitcoin Core explica que las versiones candidatas utilizan sufijos rc como rc1, rc2 y rc3. Ofrecen a los desarrolladores, operadores de nodos y empaquetadores posteriores una versión casi final para probar antes de un lanzamiento principal estable. Un número rc más alto no significa por sí solo aprobación de producción. Significa que otro candidato estaba preparado después de cambios o correcciones, y las pruebas aún pueden revelar razones para un rc4 o trabajo adicional.
La rama tiene 29 confirmaciones por delante de la etiqueta rc2.
La comparación de GitHub de v32.0rc2 con la rama 32.x mostró 29 confirmaciones en el momento de la verificación. Estos incluyen código, pruebas, documentación, ajustes de compilación y confirmaciones de generación de versiones rc3. Contar las confirmaciones no es una medida de gravedad: una pequeña solución operativa puede importar más que varias actualizaciones de la documentación. Los operadores deben leer las notas finales de la versión y examinar los subsistemas específicos que utilizan en lugar de inferir el riesgo sólo a partir del número.
El candidato lleva varios ajustes operativos
Los cambios entre rc2 y la rama actual incluyen respaldos del estimador de tarifas, eliminación de estadísticas de bloques extraídos cuando no se puede cargar el estado de mempool, drenaje de devoluciones de llamadas de tarifas antes de guardar el estado de apagado, redacción que marca la transmisión privada experimental y una categoría de depuración de minería para un registro de plantilla de bloque recurrente. Cada cambio tiene su propio alcance. El salto de rama no implica un cambio en la regla de consenso, un hash más rápido o un cambio en la prueba de trabajo.
El cambio del registro de minería se realizó por separado.
Una confirmación incluida mueve el mensaje de peso CreateNewBlock detrás de la categoría de depuración de minería. ASIC.tools cubrió ese parche por separado porque las solicitudes frecuentes de plantillas de bloque pueden generar registros repetitivos. En el contexto de rc3, es simplemente un cambio operativo respaldado entre muchos. Los administradores de grupos que requieran esa línea necesitarán la configuración de depuración relevante en una versión que la contenga; no deben asumir que todos los nodos instalados ya han cambiado de comportamiento.
Los binarios oficiales de rc3 aún no aparecían en la lista cuando se comprobaron
En la revisión editorial del 2 de octubre, el índice de descarga oficial de Bitcoin Core aún exponía el directorio candidato 32.0rc2 firmado con fecha del 22 de septiembre, mientras que un directorio rc3 aún no estaba disponible. La preparación del control de código fuente normalmente precede a las compilaciones reproducibles, las firmas y la publicación. Esta distinción de tiempo evita que un aumento de versión fusionada se informe erróneamente como software firmado descargable. La disponibilidad puede cambiar más adelante, por lo que los operadores deben verificar el índice oficial y las firmas en el momento de la descarga.
Los pools deberían probar los caminos que realmente utilizan
Los grupos de minería, las puertas de enlace individuales y los servidores de plantillas deben presentar candidatos contra getblocktemplate, estimación de tarifas, persistencia de mempool, apagado y reinicio, autenticación RPC, monitoreo y alertas. Los nodos de prueba no deben compartir secretos de la billetera de producción. Los operadores deben conservar registros y métricas comparables, verificar el comportamiento de los candidatos según tasas de solicitud de plantillas realistas y confirmar que Stratum o el software de distribución de trabajos gestiona las respuestas exactamente como se espera.
La verificación importa más que un enlace de descarga
Cuando aparecen archivos binarios, los operadores deben usar la ubicación de distribución oficial de Bitcoin Core, verificar SHA256SUMS y firmas, y comparar la política de firmante utilizada por su organización. Primero se debe instalar una versión candidata en un entorno de prueba aislado. La compilación a partir del código fuente de GitHub requiere fijar la confirmación exacta y seguir el proceso de compilación reproducible. Un enlace copiado de un foro o espejo no establece que el paquete corresponda a la rama revisada.
Qué está confirmado y qué queda pendiente
Los hechos confirmados son el salto de rama rc3 fusionado, sus tres confirmaciones de preparación y 29 confirmaciones entre la etiqueta rc2 y el encabezado 32.x marcado. La versión final oficial 32.0 aún estaba pendiente y los binarios rc3 firmados aún no eran visibles en el momento marcado. La siguiente evidencia son los artefactos candidatos oficiales, las certificaciones de compilación reproducible, los informes de los probadores y la etiqueta estable. Las actualizaciones de producción deben seguir esos artefactos, no solo el nombre de la sucursal.
Fuente: Bitcoin Core ↗
Calculadora de minería ↗
