Bitcoin Core v32.0rc1 ha abierto una ventana de pruebas especialmente concentrada para operadores de nodos, proveedores de monederos y servicios que dependen de sus interfaces RPC. La versión candidata, cuya firma verificada se publicó el 14 de septiembre, modifica varios comportamientos por defecto y puede provocar problemas temporales de compatibilidad en aplicaciones populares.
El calendario vigente sitúa el lanzamiento de la versión final v32.0 el 10 de octubre. Entre ambas fechas median 26 días, aunque la planificación ha cambiado respecto a una previsión anterior: un adelanto de agosto apuntaba al 10 de septiembre para la primera candidata. La diferencia de cuatro días no permite concluir que se incumpliera un plazo que se hubiera mantenido sin cambios.
En cualquier caso, v32.0rc1 sigue siendo software preliminar. No equivale a la versión definitiva ni implica la activación de nuevas reglas de consenso. Uno de los cambios relacionados con el borrador BIP 323 afecta a la forma en que Bitcoin Core trata los bits de señalización y las advertencias sobre despliegues desconocidos, pero la propuesta continúa en estado de borrador.
Los monederos deberán revisar el uso de PSBT
El principal foco de incompatibilidad para monederos y servicios está en varias interfaces RPC. Cuatro de ellas pasarán a utilizar PSBTv2 por defecto, mientras que otras eliminarán campos obsoletos o rechazarán argumentos que las versiones anteriores todavía aceptaban.
El cambio afecta especialmente a los equipos que crean, convierten o aumentan las comisiones de transacciones PSBT. No basta con comprobar que el nodo arranca correctamente: las transacciones deben seguirse a través de los analizadores, firmadores y demás componentes que intervienen en el flujo. Una modificación en cualquiera de esos pasos podría traducirse en errores de lectura, firma o envío.
También será necesario probar el cálculo de comisiones. La ruta predeterminada de estimatesmartfee combina los estimadores basados en la política de bloques y en la mempool, puede devolver una estimación inferior y generar un error si falla cualquiera de los dos componentes. La comprobación debe incluir el arranque del nodo y situaciones de mempool escasa o en mal estado, además de verificar que funcionan la monitorización y las alternativas explícitas basadas en la política de bloques.
Más cambios en rendimiento, HTTP y recuperación
Las notas preliminares de la versión incorporan también una modificación relevante en el procesamiento de bloques: la precarga paralela de salidas de transacciones durante la conexión de cada bloque. La configuración utiliza por defecto ocho trabajadores, permite llegar hasta 16 y puede desactivarse. El rendimiento dependerá del equipo, por lo que las pruebas deberían comparar varias configuraciones y medir el consumo de CPU, memoria y almacenamiento, especialmente en validaciones limitadas por el disco.
La reescritura del servidor HTTP amplía la superficie de compatibilidad más allá del propio nodo. Bitcoin Core introduce un límite de 8.192 bytes para las cabeceras, un tratamiento más estricto de las cabeceras malformadas, 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 cambios pueden hacerse visibles en proxies inversos, comprobaciones de estado, grupos de conexiones y gestores de errores.
La estrategia de vuelta atrás también requiere planificació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. Un descenso de versión puede obligar a reconstruirlo de nuevo, un proceso que podría prolongarse durante horas.
Por último, los operadores que priorizan la privacidad deberían reproducir los escenarios de fallo de difusión privada asociados a la corrección del mecanismo de respaldo de Tor, incluida la cola de 10.000 entradas, el límite de 1.000 intentos y el comportamiento de retransmisión bajo carga. Mientras la etiqueta final de v32.0 siga siendo solo un objetivo del calendario, estas comprobaciones forman parte del trabajo práctico de la fase candidata. La página oficial de descargas mantiene la versión 31.1 como referencia estable.
