Bitcoin Core v32.0 entra en una fase de pruebas que puede obligar a revisar la compatibilidad de carteras, servicios y herramientas conectadas a los nodos. La primera versión candidata, v32.0rc1, recibió una firma verificada el 14 de septiembre, mientras que el calendario del proyecto sitúa el 10 de octubre como objetivo para publicar la versión definitiva.
La ventana de 26 días entre ambas fechas concentra las comprobaciones de los operadores de nodos y de los equipos que dependen de las interfaces RPC de Bitcoin Core. La etiqueta «rc1» identifica software previo al lanzamiento final: no es todavía una actualización de producción ni implica la activación de nuevas reglas de consenso.
Un cambio con impacto en carteras y servicios
Uno de los principales focos de atención está en los protocolos de las transacciones parcialmente firmadas, conocidas como PSBT. Cuatro llamadas RPC pasarán a utilizar PSBTv2 por defecto, mientras que otras interfaces eliminarán campos obsoletos o dejarán de aceptar argumentos que las versiones anteriores toleraban.
El cambio afecta especialmente a los sistemas que crean, convierten o modifican las comisiones de estas transacciones. Los equipos responsables tendrán que comprobar el recorrido completo hasta los analizadores y firmantes posteriores, ya que una incompatibilidad en cualquiera de esos puntos podría interrumpir temporalmente el funcionamiento de una cartera o de un servicio conectado al nodo.
También cambia el comportamiento de la estimación de comisiones. La ruta predeterminada de estimatesmartfee combinará los estimadores basados en la política de bloques y en la mempool. Eso puede producir una estimación inferior y devolver un error si falla cualquiera de los dos componentes. Las pruebas deberán incluir el arranque del nodo y escenarios con una mempool escasa o en mal estado, además de verificar que las herramientas de monitorización y las alternativas explícitas basadas en la política de bloques responden correctamente.
Más cambios internos y nuevas condiciones para los nodos
Las notas preliminares de v32 destacan el precálculo paralelo de salidas de transacciones durante la conexión de bloques. La configuración parte de ocho trabajadores, permite llegar hasta 16 y puede desactivarse. El objetivo de las pruebas no es solo comprobar si el procesamiento de bloques es más rápido, sino medir el coste en procesador, memoria y latencia de almacenamiento en cada equipo.
La reescritura del servidor HTTP amplía la superficie que deben revisar los operadores. La nueva versión incorpora un límite de 8.192 bytes para las cabeceras, un tratamiento más estricto de las cabeceras mal formadas, un máximo predeterminado de 16 conexiones RPC, nuevos controles de caché para REST y la desconexión inmediata de direcciones de clientes no autorizadas. Estos ajustes pueden aflorar en proxies inversos, comprobaciones de estado, grupos de conexiones y gestores de errores.
El proceso de vuelta atrás también requiere precaución. El índice de transacciones reconstruido ocupa menos de la mitad del espacio en disco, pero las versiones antiguas no pueden leer el nuevo formato. Por eso, una degradación a una versión anterior puede exigir otra reconstrucción, con una duración de varias horas.
Pruebas antes del lanzamiento definitivo
La guía más reciente de Bitcoin Core recomienda probar las funciones habituales en directorios temporales de datos separados y comparar el comportamiento de la candidata con el de la versión anterior. La página oficial de descargas mantiene la versión 31.1 como referencia actual para esa comparación.
Los operadores centrados en la privacidad deberán reproducir además los fallos de difusión privada relacionados con la corrección del mecanismo alternativo de Tor, la cola de 10.000 entradas, el límite de 1.000 intentos y el comportamiento de la retransmisión bajo carga.
El calendario todavía presenta un objetivo, no una fecha definitiva. La previsión inicial recogida en agosto apuntaba al 10 de septiembre para la primera candidata, mientras que el calendario actualizado marca el 14 de septiembre; la diferencia de cuatro días no permite concluir que se incumpliera un plazo sin cambios. En cualquier caso, el periodo hasta el lanzamiento final será el banco de pruebas para detectar incompatibilidades antes de que v32.0 llegue a los entornos de producción.
