Bitcoin Core 32 : validation accélérée et ajustements des frais

Bitcoin Core 32.0 est entré dans son cycle final de test de version candidate après que les développeurs ont étiqueté v32.0rc1 le 14 septembre, rapprochant l'estimation des frais, les performances de validation des blocs et les correctifs de sécurité d'une sortie prévue le 10 octobre.

La version officielle sur GitHub du projet Bitcoin Core montre v32.0rc1 au commit d0231bb, signé avec une signature de mainteneur vérifiée le 14 septembre à 12:58 UTC. Le calendrier de sortie du projet cible toujours le 10 octobre pour l'étiquette finale v32.0, bien que la date reste soumise aux tests et à d'autres correctifs.

La version 32 se concentre sur le comportement du logiciel de nœud, les interfaces de portefeuille, le calcul des frais, la mise en réseau et les performances. Les notes de version préliminaires ne listent aucun changement aux règles de consensus de Bitcoin, ce qui signifie que la mise à jour ne redéfinit pas quelles transactions ou quels blocs le réseau considère comme valides.

Bitcoin Core 32 vise le 10 octobre après l'étiquette RC1

Les développeurs sont entrés en gel des fonctionnalités le 20 août, limitant le travail aux correctifs nécessaires avant la sortie. Le 14 septembre, ils ont séparé la branche 32.x de la branche de développement principale et ont commencé le cycle de version candidate tandis que le travail de développement pour la version 33 reprenait séparément.

Le premier candidat est destiné aux opérateurs de nœuds, aux développeurs de portefeuilles et à d'autres utilisateurs pour tester avant que les développeurs ne décident si le code est prêt pour une version stable. Bitcoin Core a ouvert un problème dédié aux retours de test de la version candidate 32.0 le 15 septembre, un jour après l'étiquetage de RC1.

Le projet demande aux testeurs d'utiliser le guide de test pour les vérifications spécifiques à la RC et de signaler les problèmes logiciels via des problèmes GitHub séparés. Aucun binaire final v32.0 n'a été publié au 16 septembre.

Bitcoin Core ne se met pas à jour automatiquement. Les opérateurs choisissent quand installer les nouvelles versions, ce qui signifie que les anciennes versions peuvent rester actives après la disponibilité de logiciels plus récents.

Ce modèle de mise à niveau manuelle a compté dans les précédentes divulgations de sécurité. Comme crypto.news l'a précédemment rapporté, Bitcoin Core a divulgué CVE-2024-52911 en mai après que la branche vulnérable 28.x a atteint sa fin de vie. Le bug avait déjà été corrigé dans Bitcoin Core 29.0 avant que les détails techniques ne deviennent publics.

Le nouvel estimateur de frais mélange mempool et historique des blocs

L'un des changements les plus visibles pour l'utilisateur de Bitcoin Core 32 affecte estimatesmartfee, le RPC utilisé par les portefeuilles et les applications pour calculer les frais de transaction.

Jusqu'à présent, l'estimateur principal de Bitcoin Core s'est appuyé sur le comportement de confirmation observé des transactions incluses dans les blocs passés. La version 32 ajoute un estimateur séparé basé sur les transactions actuellement en attente dans le mempool du nœud.

Le nouvel estimateur de mempool produit à la fois des estimations économiques et conservatrices à partir des conditions actuelles des transactions en attente. Bitcoin Core vérifie l'activité récente des blocs avant de l'utiliser et peut rejeter l'estimation lorsque le mempool semble trop clairsemé ou malsain.

Lorsque les deux systèmes produisent des résultats valides, estimatesmartfee renvoie l'estimation de frais la plus basse. La nouvelle méthode ne peut donc pas pousser la recommandation existante de politique de bloc plus haut via le mode par défaut combiné ; son rôle est d'abaisser la recommandation lorsque les conditions actuelles du mempool le permettent.

Cette conception peut réagir plus rapidement après la fin d'une période d'espace de bloc coûteux. Un estimateur basé sur l'historique des blocs peut continuer à incorporer des transactions récemment confirmées à frais élevés, tandis que le mempool peut déjà montrer moins de transactions en compétition pour confirmation.

Le logiciel préserve un moyen pour les applications d'utiliser la méthode précédente. Une option ajoutée fee_rate_estimator permet aux utilisateurs de demander block_policy, mempool_policy ou le comportement par défaut combiné. Bitcoin Core stocke les statistiques du nouvel estimateur de mempool dans un fichier de données séparé afin qu'elles puissent être rechargées après redémarrage.

Les calculs de frais du portefeuille utiliseront l'estimateur par défaut combiné. La réponse peut identifier quel estimateur a produit les frais sélectionnés, tandis que des niveaux de verbosité plus élevés exposent les statistiques de santé du mempool pour les applications qui ont besoin de plus de détails.

La validation de bloc bénéficie d'un préchargement disque parallèle

Bitcoin Core 32 modifie la façon dont les nœuds récupèrent les données de transaction lors de la connexion des blocs, en particulier lorsque les informations nécessaires doivent être lues depuis le stockage.

Le logiciel peut désormais précharger les sorties de transaction précédentes, appelées prevouts, depuis la base de données chainstate sur plusieurs threads de travail pendant que la validation de bloc continue. La valeur par défaut est de huit threads de préchargement, les opérateurs pouvant augmenter le paramètre à 16 ou désactiver la récupération parallèle en le réglant à zéro.

Les prevouts identifient les pièces dépensées par les entrées de transaction. Les nœuds ont besoin de ces informations pour vérifier si les entrées existent, n'ont pas déjà été dépensées et satisfont aux règles de validation applicables.

L'amélioration vise à réduire le temps d'attente pour les lectures disque lorsqu'un nœud traite des blocs contenant des entrées non déjà disponibles dans des caches mémoire plus rapides. L'effet variera selon le matériel de stockage, le comportement du cache et la configuration du nœud.

Bitcoin Core 32 expose le paramètre via -prevoutfetchthreads=<n>, donnant aux opérateurs le contrôle du nombre de threads participants. Les notes préliminaires décrivent la fonctionnalité spécifiquement comme une amélioration des performances de validation de bloc.

Des modifications RPC distinctes donnent aux opérateurs plus d'informations pendant la validation en arrière-plan d'AssumeUTXO. Après qu'un nœud basé sur un instantané atteint la pointe de la chaîne, getblockchaininfo peut désormais signaler la progression de la validation historique de la chaîne toujours en cours derrière l'état actif du nœud.

Des correctifs de sécurité colmatent des failles mémoire du portefeuille et HTTP

Bitcoin Core 32 corrige une faille de notification de portefeuille affectant les systèmes non Windows dans un ensemble restreint de conditions.

Les notes préliminaires indiquent qu'un utilisateur RPC authentifié ayant la permission de créer des portefeuilles pouvait fabriquer un nom de portefeuille contenant des caractères de remplacement spéciaux lorsque le nœud était configuré avec -walletnotify. Dans ces conditions, le nom pouvait entraîner l'exécution de commandes arbitraires avec les privilèges du processus Bitcoin Core.

La version 32 modifie le remplacement des espaces réservés dans les notifications de portefeuille afin que les noms de portefeuille soient traités comme du texte littéral. La version renforce également le nommage des portefeuilles en rejetant certains noms de chemin relatif contenant des éléments de chemin . ou ..

Un second problème est apparu lors de l'examen du serveur HTTP réécrit de Bitcoin Core, qui remplace libevent dans la version 32.

Le développeur Matthew Zipkin a soumis la pull request #36123 après qu'un audit utilisant le modèle Kimi K3 de Moonshot AI a identifié un chemin d'épuisement de mémoire. Alors que le serveur traitait une requête, il pouvait continuer à lire et mettre en file d'attente les données envoyées par la même connexion sans limite de taille effective.

La première analyse suggérait que la condition nécessitait principalement un client authentifié capable de maintenir une requête occupée. Des tests supplémentaires ont révélé que le trafic REST créait un problème similaire sans authentification.

Un réviseur a signalé que 16 connexions REST non authentifiées ont fait passer un processus de test de 46 Mo de mémoire à environ 3 Go en une minute environ. Après le correctif révisé, le même test a augmenté l'utilisation de la mémoire d'environ 3 Mo sur 90 secondes, contre 3,2 Go avant le correctif.

Le correctif a été fusionné le 5 septembre, avant que v32.0rc1 ne soit étiqueté. Comme le serveur HTTP réécrit est nouveau dans la version 32, la faille spécifique a été détectée avant que le serveur n'apparaisse dans une version stable de Bitcoin Core.

L'utilisation de Kimi K3 s'inscrit dans un schéma récent de révision de sécurité assistée par IA dans les logiciels Bitcoin. Comme crypto.news l'a rapporté en août, Bitcoin Red Team avait enregistré 7 958 constatations potentielles après avoir scanné des centaines de projets open source liés à Bitcoin, bien que beaucoup nécessitaient une vérification humaine avant de pouvoir être traitées comme des vulnérabilités confirmées.

Des problèmes d'épuisement des ressources sont apparus dans d'autres logiciels Bitcoin cette année. Dans une couverture connexe, crypto.news a rapporté que Core Lightning a confirmé des failles de sécurité après avoir examiné des rapports générés par IA et a averti les opérateurs de mettre à niveau ou d'utiliser temporairement le mode hors ligne.

PSBT version 2 devient la valeur par défaut pour quatre RPC

Bitcoin Core 32 modifie le format par défaut créé par quatre commandes utilisées avec les transactions Bitcoin partiellement signées.

createpsbt, walletcreatepsbt, converttopsbt et psbtbumpfee produiront par défaut des PSBT version 2. Les développeurs ont ajouté un argument optionnel psbt_version afin que les applications puissent demander explicitement une autre version prise en charge lorsque cela est nécessaire.

Les PSBT permettent à plusieurs portefeuilles, applications ou dispositifs de signature matériels d'échanger des informations de transaction avant que la transaction Bitcoin complète ne soit diffusée. Le passage de la valeur par défaut à la version 2 peut nécessiter des tests par les logiciels qui supposent que la sortie RPC de Core utilisera l'ancien format.

La mise à jour ne supprime pas la possibilité de demander la version précédente. Les applications construites autour des commandes RPC concernées peuvent définir le format explicitement pendant qu'elles testent la compatibilité avec la version 2.

Les outils de portefeuille reçoivent d'autres changements dans la même version. Une nouvelle RPC exportwatchonlywallet crée un fichier de portefeuille descriptor contenant des descripteurs publics, l'historique des transactions et les données du carnet d'adresses sans clés privées. Le tutoriel de signature hors ligne de Bitcoin Core utilise désormais cette commande pour créer un portefeuille en ligne en lecture seule.

Une autre nouvelle commande, derivehdkey, permet à un portefeuille de dériver une clé publique ou privée étendue via un chemin contenant au moins une étape renforcée, tandis que addhdkey permet d'ajouter une clé étendue BIP32 sans l'utiliser immédiatement pour générer des scripts de sortie.

PrivateBroadcast reçoit également une maintenance continue. Crypto.news a rapporté en juin que Bitcoin Core 31.1rc1 a corrigé une condition réseau qui pouvait exposer une adresse IP d'origine lorsque PrivateBroadcast était utilisé. La version 32 contient d'autres modifications de PrivateBroadcast RPC et de relais de transactions documentées dans ses notes de version préliminaires.

Le calendrier actuel de Bitcoin Core indique toujours le 10 octobre comme objectif pour l'étiquetage de la v32.0. Le fil de discussion pour les retours de test RC ouvert le 15 septembre reste actif, les développeurs demandant aux testeurs qui trouvent de véritables défauts de Bitcoin Core de soumettre des problèmes séparés avant la version finale.