Bitcoin Core 32.0 ha entrado en su ciclo final de pruebas de candidato a lanzamiento después de que los desarrolladores etiquetaran v32.0rc1 el 14 de septiembre, acercando la estimación de comisiones, el rendimiento de validación de bloques y las correcciones de seguridad a un lanzamiento planeado para el 10 de octubre.
Resumen
- Bitcoin Core 32.0 entró en pruebas de candidato a lanzamiento el 14 de septiembre, con el etiquetado final previsto para el 10 de octubre.
- La nueva estimación de comisiones combina el historial de bloques con las condiciones actuales de la mempool y puede recomendar comisiones más bajas.
- La validación de bloques ahora precarga las salidas anteriores en ocho hilos de trabajo por defecto, reduciendo las esperas de disco.
- Un fallo en la notificación de la billetera podría permitir a usuarios autenticados ejecutar comandos en sistemas de nodo afectados que no sean Windows.
- Las pruebas encontraron que dieciséis conexiones REST no autenticadas podían llevar el uso de memoria a aproximadamente tres gigabytes rápidamente.
El lanzamiento oficial en GitHub del proyecto Bitcoin Core muestra v32.0rc1 en el commit d0231bb, firmado con una firma de mantenedor verificada el 14 de septiembre a las 12:58 UTC. El calendario de lanzamiento del proyecto sigue apuntando al 10 de octubre para la etiqueta final v32.0, aunque la fecha sigue sujeta a pruebas y más correcciones.
La versión 32 se centra en el comportamiento del software de nodo, las interfaces de billetera, el cálculo de comisiones, la red y el rendimiento. Las notas de lanzamiento preliminares no enumeran un cambio en las reglas de consenso de Bitcoin, lo que significa que la actualización no redefine qué transacciones o bloques considera válidos la red.
Bitcoin Core 32 apunta al 10 de octubre tras la etiqueta RC1
Los desarrolladores entraron en congelación de características el 20 de agosto, limitando el trabajo a las correcciones necesarias antes del lanzamiento. El 14 de septiembre, separaron la rama 32.x de la rama principal de desarrollo y comenzaron el ciclo de candidato a lanzamiento mientras el trabajo de desarrollo para la versión 33 se reanudaba por separado.
El primer candidato está destinado a que operadores de nodos, desarrolladores de billeteras y otros usuarios lo prueben antes de que los desarrolladores decidan si el código está listo para un lanzamiento estable. Bitcoin Core abrió un problema dedicado de comentarios sobre las pruebas del candidato a lanzamiento 32.0 el 15 de septiembre, un día después de que se etiquetara RC1.
El proyecto pide a los probadores que utilicen la guía de pruebas para verificaciones específicas de RC y que informen problemas de software a través de problemas separados en GitHub. No se ha lanzado ningún binario final v32.0 hasta el 16 de septiembre.
Bitcoin Core no se actualiza automáticamente. Los operadores eligen cuándo instalar nuevas versiones, lo que significa que las versiones anteriores pueden permanecer activas después de que el software más nuevo esté disponible.
Ese modelo de actualización manual ha importado en divulgaciones de seguridad anteriores. Como crypto.news informó anteriormente, Bitcoin Core divulgó CVE-2024-52911 en mayo después de que la rama vulnerable 28.x llegara al final de su vida útil. El error ya había sido corregido en Bitcoin Core 29.0 antes de que los detalles técnicos se hicieran públicos.
El nuevo estimador de comisiones combina mempool e historial de bloques
Uno de los cambios más visibles para el usuario de Bitcoin Core 32 afecta a estimatesmartfee, el RPC utilizado por billeteras y aplicaciones para calcular comisiones de transacción.
Hasta ahora, el estimador principal de Bitcoin Core se ha basado en el comportamiento de confirmación observado de transacciones incluidas en bloques pasados. La versión 32 añade un estimador separado basado en transacciones que actualmente esperan dentro de la mempool del nodo.
El nuevo estimador de mempool produce estimaciones tanto económicas como conservadoras a partir de las condiciones actuales de las transacciones pendientes. Bitcoin Core verifica la actividad reciente de bloques antes de usarlo y puede rechazar la estimación cuando la mempool parece demasiado dispersa o poco saludable.
Cuando ambos sistemas producen resultados válidos, estimatesmartfee devuelve la estimación de comisión más baja. Por lo tanto, el nuevo método no puede elevar la recomendación existente de política de bloques a través del modo predeterminado combinado; su función es reducir la recomendación cuando las condiciones actuales de la mempool lo respaldan.
Ese diseño puede responder más rápidamente después de que termina un período de espacio de bloque costoso. Un estimador basado en el historial de bloques puede seguir incorporando transacciones recientemente confirmadas con comisiones altas, mientras que la mempool ya podría mostrar menos transacciones compitiendo por confirmación.
El software conserva una forma para que las aplicaciones usen el método anterior. Una opción añadida fee_rate_estimator permite a los usuarios solicitar block_policy, mempool_policy o el comportamiento predeterminado combinado. Bitcoin Core almacena las estadísticas del nuevo estimador de mempool en un archivo de datos separado para que puedan recargarse tras reiniciar.
Los cálculos de comisiones de la billetera usarán el estimador predeterminado combinado. La respuesta puede identificar qué estimador produjo la comisión seleccionada, mientras que los niveles de verbosidad más altos exponen estadísticas de salud de la mempool para aplicaciones que necesitan más detalle.
La validación de bloques obtiene prelectura paralela de disco
Bitcoin Core 32 cambia cómo los nodos recuperan datos de transacciones mientras conectan bloques, particularmente cuando la información necesaria debe leerse del almacenamiento.
El software ahora puede preleer salidas de transacciones anteriores, conocidas como prevouts, desde la base de datos del estado de la cadena a través de varios hilos de trabajo mientras la validación de bloques continúa. El valor predeterminado es ocho hilos de prelectura, y los operadores pueden elevar la configuración a 16 o desactivar la obtención paralela estableciéndola en cero.
Los prevouts identifican las monedas que están siendo gastadas por las entradas de transacción. Los nodos necesitan esa información para verificar si las entradas existen, no han sido ya gastadas y cumplen las reglas de validación aplicables.
La mejora está destinada a reducir el tiempo dedicado a esperar lecturas de disco cuando un nodo procesa bloques que contienen entradas que aún no están disponibles en cachés de memoria más rápidas. El efecto variará según el hardware de almacenamiento, el comportamiento de la caché y la configuración del nodo.
Bitcoin Core 32 expone la configuración a través de -prevoutfetchthreads=<n>, dando a los operadores control sobre cuántos hilos participan. Las notas del borrador describen la característica específicamente como una mejora de rendimiento de la validación de bloques.
Cambios separados en RPC brindan a los operadores más información durante la validación en segundo plano de AssumeUTXO. Después de que un nodo basado en instantánea alcanza la punta de la cadena, getblockchaininfo ahora puede informar el progreso de la validación histórica de la cadena que aún se ejecuta detrás del estado activo del nodo.
Correcciones de seguridad cierran fallos de memoria en la billetera y HTTP
Bitcoin Core 32 corrige un fallo de notificación de billetera que afecta a sistemas no Windows bajo un conjunto limitado de condiciones.
Las notas del borrador indican que un usuario RPC autenticado con permiso para crear billeteras podría elaborar un nombre de billetera que contuviera caracteres de reemplazo especiales cuando el nodo estaba configurado con -walletnotify. Bajo esas condiciones, el nombre podría provocar la ejecución de comandos arbitrarios con los privilegios del proceso de Bitcoin Core.
La versión 32 cambia el reemplazo de marcadores de posición de notificación de billetera para que los nombres de billetera se traten como texto literal. La versión también endurece la denominación de billeteras al rechazar ciertos nombres de rutas relativas que contienen elementos de ruta . o ..
Un segundo problema surgió durante la revisión del servidor HTTP reescrito de Bitcoin Core, que está reemplazando a libevent en la versión 32.
El desarrollador Matthew Zipkin envió la solicitud de extracción #36123 después de que una auditoría usando el modelo Kimi K3 de Moonshot AI identificara una ruta de agotamiento de memoria. Mientras el servidor gestionaba una solicitud, podía seguir leyendo y poniendo en cola datos enviados por la misma conexión sin un límite de tamaño efectivo.
El primer análisis sugirió que la condición requería principalmente un cliente autenticado capaz de mantener ocupada una solicitud. Pruebas posteriores encontraron que el tráfico REST creaba un problema similar sin autenticación.
Un revisor informó que 16 conexiones REST no autenticadas llevaron un proceso de prueba de 46 MB de memoria a aproximadamente 3 GB en alrededor de un minuto. Después de la corrección revisada, la misma prueba aumentó el uso de memoria en aproximadamente 3 MB durante 90 segundos, en comparación con 3,2 GB antes del parche.
El parche se fusionó el 5 de septiembre, antes de que se etiquetara v32.0rc1. Debido a que el servidor HTTP reescrito es nuevo en la versión 32, el fallo específico se detectó antes de que el servidor apareciera en una versión estable de Bitcoin Core.
El uso de Kimi K3 se ajusta a un patrón reciente de revisión de seguridad asistida por IA en el software de Bitcoin. Como crypto.news informó en agosto, Bitcoin Red Team había registrado 7.958 hallazgos potenciales después de escanear cientos de proyectos de código abierto relacionados con Bitcoin, aunque muchos requerían verificación humana antes de poder ser tratados como vulnerabilidades confirmadas.
Los problemas de agotamiento de recursos han aparecido en otro software de Bitcoin este año. En cobertura relacionada, crypto.news informó que Core Lightning confirmó fallos de seguridad después de revisar informes generados por IA y advirtió a los operadores que actualizaran o usaran temporalmente el modo sin conexión.
PSBT versión 2 se convierte en el predeterminado para cuatro RPC
Bitcoin Core 32 cambia el formato predeterminado creado por cuatro comandos utilizados con Transacciones de Bitcoin Parcialmente Firmadas.
createpsbt, walletcreatepsbt, converttopsbt y psbtbumpfee producirán PSBT versión 2 de forma predeterminada. Los desarrolladores añadieron un argumento opcional psbt_version para que las aplicaciones puedan solicitar explícitamente otra versión compatible cuando sea necesario.
Los PSBT permiten que varios monederos, aplicaciones o dispositivos de firma de hardware intercambien información de transacciones antes de que se difunda la transacción de Bitcoin completada. Cambiar el valor predeterminado a la versión 2 puede requerir pruebas por parte del software que asume que la salida RPC de Core utilizará el formato anterior.
La actualización no elimina la capacidad de solicitar la versión anterior. Las aplicaciones construidas en torno a los comandos RPC afectados pueden establecer el formato explícitamente mientras prueban la compatibilidad con la versión 2.
Las herramientas de monedero reciben otros cambios en la misma versión. Un nuevo RPC exportwatchonlywallet crea un archivo de monedero descriptor que contiene descriptores públicos, historial de transacciones y datos de la libreta de direcciones sin claves privadas. El tutorial de firma sin conexión de Bitcoin Core ahora utiliza ese comando para crear un monedero de solo observación en línea.
Otro nuevo comando, derivehdkey, permite a un monedero derivar una clave pública o privada extendida a través de una ruta que contiene al menos un paso endurecido, mientras que addhdkey permite añadir una clave extendida BIP32 sin usarla inmediatamente para generar scripts de salida.
PrivateBroadcast también recibe mantenimiento continuo. Crypto.news informó en junio que Bitcoin Core 31.1rc1 corrigió una condición de red que podía exponer una dirección IP de origen cuando se utilizaba PrivateBroadcast. La versión 32 contiene más cambios en RPC de PrivateBroadcast y en el retransmisión de transacciones documentados en sus notas de versión preliminares.
El calendario actual de Bitcoin Core todavía enumera el 10 de octubre como objetivo para etiquetar la v32.0. El hilo de comentarios de pruebas de RC abierto el 15 de septiembre permanece activo, con desarrolladores indicando a los probadores que encuentren defectos reales de Bitcoin Core que presenten problemas por separado antes de la versión final.
