Bitcoin Core v32.0rc1 incorpora cambios en protocolos de monedero y podría provocar interrupciones en apps
Resumen del mercado generado por IA
Bitcoin Core v32.0rc1 concentra una ventana de compatibilidad a corto plazo de cara a una versión final prevista para el 10 de octubre, con cambios significativos en el comportamiento de monedero/RPC (valores predeterminados de PSBTv2, eliminación de campos obsoletos, gestión más estricta de argumentos) y una reescritura del servidor HTTP que puede romper herramientas, proxys y grupos de clientes. Aunque no se implica ninguna activación de reglas de consenso, los riesgos de integración y reversión elevan la incertidumbre operativa para monederos, servicios y operadores de nodos.
Nivel de impacto
● Media
Activos afectados
BTC/USDT-2.98%
Ideas de IA · BTC/USDTIdeas de IA
● Neutral
Haz trading ahora
⚠️ Las ideas generadas por IA se basan en contenido de noticias y se proporcionan solo con fines informativos. No constituyen asesoramiento de inversión ni representan los puntos de vista de BingX. Invertir implica riesgos. Opera de forma responsable.
Bitcoin Core v32.0rc1 convierte el periodo del 14 de septiembre al 10 de octubre en una prueba intensiva de compatibilidad para operadores de nodos, proveedores de monederos y servicios que dependen de las interfaces RPC de Bitcoin Core. El candidato se etiquetó con una firma verificada el 14 de septiembre. El calendario oficial de lanzamientos fija el 10 de octubre como objetivo para la etiqueta final v32.0, lo que deja un intervalo de 26 días.
Un avance publicado por CryptoSlate en agosto apuntaba al 10 de septiembre como fecha objetivo para RC1, mientras que el calendario vigente muestra ahora el 14 de septiembre. La diferencia es de cuatro días, sin que quede establecido que se incumpliera un plazo que se mantuviera sin cambios.
La etiqueta v32.0rc1 corresponde a software de prelanzamiento, no a una actualización final para producción. Tampoco implica la activación de nuevas reglas de consenso. Un ajuste asociado al borrador BIP 323 modifica cómo Bitcoin Core trata los bits de señalización y las advertencias de despliegues desconocidos, aunque la propuesta sigue en estado Draft.
Para comenzar las pruebas, los operadores pueden seguir el enfoque de la guía más reciente de testeo de RC: ejecutar funciones de uso habitual en directorios temporales de datos separados y comparar el candidato con la versión anterior. En la página oficial de descargas, 31.1 figura como base actual. Este contraste permite detectar cambios en el arranque del nodo, el comportamiento del monedero y las respuestas RPC sin tratar el candidato como una actualización rutinaria de producción.
En las notas preliminares de v32, el mayor cambio de rendimiento es la precarga paralela de salidas de transacciones durante la conexión de bloques. La opción se configura por defecto con ocho "workers", admite hasta 16 y puede desactivarse. Probar validación limitada por disco con varios ajustes ayuda a determinar si el mayor ritmo de procesamiento de bloques compensa el posible coste en CPU, memoria o latencia de almacenamiento en el hardware del operador.
En integraciones de monederos y servicios, el riesgo de rotura es independiente. Cuatro RPC pasarán a usar PSBTv2 por defecto, mientras que otras interfaces eliminan campos obsoletos o rechazan argumentos que versiones anteriores aceptaban. Los equipos que crean, convierten o ajustan comisiones ("feebump") en PSBT deberían seguir el recorrido de esas transacciones por sus analizadores y firmadores posteriores.
La gestión de comisiones también requiere pruebas de rutas de fallo. El comportamiento por defecto de estimatesmartfee combina estimadores de blockpolicy y mempool, puede devolver una estimación más baja y puede fallar si alguno de los componentes falla. Conviene observar el arranque y escenarios con mempool poco poblado o en mal estado, y confirmar que la monitorización y los mecanismos de respaldo explícitos de blockpolicy funcionan como se espera.
La reescritura del servidor HTTP amplía el alcance de las pruebas más allá del nodo. Introduce un límite de cabecera de 8.192 bytes, un manejo más estricto de cabeceras mal formadas, un techo por defecto de 16 conexiones RPC, nuevos controles de caché REST y desconexión inmediata de direcciones cliente no autorizadas. Estos cambios pueden aflorar en proxys inversos, comprobaciones de salud, pools de clientes y gestores de errores.
El plan de reversión merece la misma atención. Un índice de transacciones reconstruido usa menos de la mitad del espacio en disco, pero versiones antiguas no pueden leer el nuevo formato, por lo que una bajada de versión puede forzar otra reconstrucción que dure horas.
Los operadores centrados en privacidad deberían reproducir también las rutas de fallo de "privatebroadcast" alrededor de la corrección del fallback de Tor, la cola de 10.000 entradas, el límite de 1.000 intentos y el comportamiento de retransmisión bajo carga. Con la etiqueta final aún marcada como objetivo, estos casos límite son el trabajo práctico del periodo de RC.