Por Canuto  

Bitcoin Core 32 entró en su fase final de pruebas con cambios que pueden acelerar la validación de bloques, ajustar las recomendaciones de comisiones y cerrar fallas de seguridad antes del lanzamiento previsto para el 10 de octubre.

***

  • Bitcoin Core 32.0rc1 fue etiquetado el 14 de septiembre y la versión estable mantiene como fecha objetivo el 10 de octubre.
  • El nuevo estimador combina el historial de bloques con el estado actual del mempool y puede recomendar comisiones más bajas.
  • La actualización incorpora precarga de prevouts con ocho hilos por defecto, además de correcciones para wallets, REST y PSBT.

 

 

Bitcoin Core 32.0 entró en su ciclo final de pruebas después de que los desarrolladores etiquetaran la versión 32.0rc1 el 14 de septiembre. El calendario del proyecto mantiene el 10 de octubre como fecha objetivo para publicar la etiqueta estable, aunque la decisión todavía depende de nuevas pruebas y de la corrección de problemas que puedan aparecer durante la revisión.

La actualización se concentra en el funcionamiento de los nodos, las interfaces de wallet, el cálculo de comisiones, la conectividad y el rendimiento de validación. Las notas preliminares no describen cambios en las reglas de consenso de Bitcoin, por lo que Bitcoin Core 32 no redefine qué transacciones o bloques considera válidos la red.

El lanzamiento de prueba aparece identificado en GitHub mediante el commit d0231bb, firmado con una firma verificada de un maintainer a las 12:58 UTC del 14 de septiembre. El proyecto abrió el 15 de septiembre un espacio específico para recibir comentarios sobre la release candidate y pidió a los operadores reportar los defectos mediante incidencias separadas.

Una nueva lógica para estimar las comisiones

Uno de los cambios más visibles para usuarios de wallets y aplicaciones afecta a estimatesmartfee, el RPC utilizado para calcular cuánto pagar por una transacción. Hasta ahora, el estimador principal se apoyaba en el comportamiento de confirmación observado en operaciones incluidas en bloques anteriores, una referencia útil, pero potencialmente lenta para reflejar un cambio reciente en la congestión.

Bitcoin Core 32 añade un estimador separado que analiza las transacciones que permanecen pendientes en el mempool del nodo. Ese mecanismo produce estimaciones económicas y conservadoras a partir de las condiciones actuales, aunque primero verifica la actividad reciente de bloques y puede descartar el resultado cuando considera que el mempool es demasiado pequeño o no refleja un estado saludable.

Cuando ambos métodos entregan resultados válidos, estimatesmartfee selecciona la comisión más baja. El diseño busca reducir la recomendación cuando termina un periodo de alta competencia por espacio de bloque, pues el historial puede seguir reflejando transacciones caras aunque el conjunto de operaciones pendientes ya se haya reducido.

Las aplicaciones conservan la posibilidad de elegir el método anterior mediante la opción fee_rate_estimator, que permite solicitar block_policy, mempool_policy o el comportamiento combinado predeterminado. Bitcoin Core también guarda las estadísticas del estimador de mempool en un archivo separado para recargarlas después de un reinicio, mientras las wallets continúan usando por defecto la modalidad combinada.

Validación paralela y mayor información para los nodos

La versión 32 modifica la forma en que los nodos recuperan datos de transacciones al conectar bloques, especialmente cuando la información necesaria no está disponible en las cachés de memoria. El software puede precargar desde la base de datos chainstate los outputs de transacciones previas, conocidos como prevouts, mientras la validación del bloque continúa.

La configuración predeterminada utiliza ocho hilos de trabajo para esa precarga, aunque los operadores pueden elevarla a 16 o desactivar el procesamiento paralelo fijando el ajuste en cero. La opción queda expuesta mediante -prevoutfetchthreads=<n>, de modo que cada operador puede adaptarla a las características del almacenamiento y del hardware disponible.

Los prevouts permiten comprobar que las monedas gastadas por las entradas de una transacción existen, no fueron utilizadas anteriormente y cumplen las reglas aplicables. Al adelantar esas lecturas, Bitcoin Core intenta reducir las esperas de disco cuando un bloque contiene datos que no caben en las cachés más rápidas, aunque el beneficio final dependerá de la unidad de almacenamiento y de la configuración del nodo.

Otros cambios RPC aportan más visibilidad sobre la validación histórica que ocurre detrás de un nodo basado en AssumeUTXO. Después de que el snapshot alcance la punta de la cadena, getblockchaininfo puede informar el progreso de la validación de la cadena histórica que todavía se ejecuta en segundo plano.

Correcciones de seguridad y cambios en wallets

Bitcoin Core 32 corrige una falla de notificación de wallet que afectaba a sistemas distintos de Windows bajo condiciones específicas. Según las notas preliminares, un usuario RPC autenticado con permiso para crear wallets podía preparar un nombre con caracteres especiales de reemplazo cuando el nodo utilizaba -walletnotify, lo que podía provocar la ejecución de comandos con los privilegios del proceso de Bitcoin Core.

La corrección cambia el reemplazo de marcadores en las notificaciones para que los nombres de wallet se traten como texto literal. Además, el software rechaza ciertos nombres de rutas relativas que incluyen elementos como . o .., una medida destinada a endurecer el manejo de rutas y reducir comportamientos inesperados en configuraciones vulnerables.

Durante la revisión del servidor HTTP reescrito, una auditoría asistida por el modelo Kimi K3 de Moonshot AI identificó una posible vía de agotamiento de memoria. El problema permitía que el servidor siguiera leyendo y acumulando datos enviados por una misma conexión sin un límite efectivo, mientras procesaba una solicitud.

Las pruebas posteriores descubrieron que el riesgo también podía activarse mediante tráfico REST sin autenticación. Un revisor informó que 16 conexiones REST no autenticadas elevaron un proceso de prueba de 46 MB a aproximadamente 3 GB en cerca de un minuto; después del parche, la misma prueba aumentó el consumo en unos 3 MB durante 90 segundos, frente a 3,2 GB antes de la corrección.

PSBT 2 y nuevas herramientas para operadores

Cuatro comandos relacionados con Partially Signed Bitcoin Transactions cambiarán su formato predeterminado en Bitcoin Core 32. createpsbt, walletcreatepsbt, converttopsbt y psbtbumpfee producirán PSBT versión 2, aunque las aplicaciones podrán solicitar de forma explícita otra versión compatible mediante el argumento opcional psbt_version.

Las PSBT permiten que wallets, aplicaciones y dispositivos de firma de hardware intercambien información antes de difundir una transacción completa en la red. El cambio puede exigir pruebas adicionales para el software que asuma que la respuesta RPC de Bitcoin Core siempre utiliza el formato anterior, pero no elimina la capacidad de pedir ese formato cuando sea necesario.

El lanzamiento también incorpora exportwatchonlywallet, un RPC que crea un archivo de wallet descriptor con descriptores públicos, historial de transacciones y datos de la libreta de direcciones, sin incluir claves privadas. El tutorial de firma offline de Bitcoin Core ya utiliza ese comando para preparar una wallet de solo observación conectada a Internet.

Otro comando nuevo, derivehdkey, permite derivar una clave pública o privada extendida mediante una ruta que contenga al menos un paso hardened, mientras addhdkey agrega una clave extendida BIP32 sin utilizarla inmediatamente para generar scripts de salida. PrivateBroadcast recibe cambios adicionales en el RPC y en la retransmisión de transacciones, después de ajustes anteriores relacionados con la exposición de direcciones IP de origen.

Qué deben considerar los operadores antes del lanzamiento

Bitcoin Core no actualiza los nodos automáticamente, por lo que cada operador decide cuándo instalar una versión nueva. Ese modelo permite que versiones antiguas continúen activas después de una publicación estable y vuelve especialmente importante revisar las correcciones de seguridad antes de mantener una infraestructura expuesta.

La versión 32 todavía no tenía un binario final al 16 de septiembre de 2026, mientras la rama 32.x avanzaba de forma separada del desarrollo de la versión 33. Los desarrolladores habían congelado las funciones el 20 de agosto y limitaron el trabajo posterior a correcciones necesarias para reducir el riesgo de introducir cambios tardíos.

La revisión de seguridad asistida por inteligencia artificial forma parte de un patrón más amplio dentro del ecosistema de software de Bitcoin. Bitcoin Red Team había registrado 7.958 hallazgos potenciales tras analizar cientos de proyectos relacionados, aunque esos resultados requieren validación humana antes de considerarse vulnerabilidades confirmadas.

El calendario puede cambiar si las pruebas encuentran defectos en la release candidate, y el proyecto pidió que los problemas reales se documenten en incidencias independientes antes de la etiqueta final. Para los operadores, la combinación de mejores estimaciones, precarga paralela, cambios de PSBT y correcciones de seguridad convierte a Bitcoin Core 32 en una actualización técnica relevante, aunque no en una modificación del consenso de Bitcoin.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

 


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados