Le 14 septembre, l'équipe Bitcoin Core a publié la première version candidate v32.0rc1. La mise à jour modifiera le mécanisme d'évaluation des frais, accélérera la validation des blocs lors de la lecture des données à partir du disque et corrigera la vulnérabilité. notifier le portefeuille. Cette dernière n'affecte qu'une configuration spécifique et nécessite un identifiant authentifié. RPC-accès, découle du calendrier officiel et des projets de notes de version.
La sortie de Stable Bitcoin Core 32.0 est prévue pour le 10 octobre. Les notes de version publiées ne contiennent pas de modifications aux règles de consensus Bitcoin : elles parlent de mise à jour du logiciel client.
Les estimations de frais tiendront compte de l'état du mempool
Dans Bitcoin Core 32.0, l'équipe modifiera le fonctionnement des estimationsmartfee , qui permet de déterminer les frais pour confirmer une transaction pour un nombre de blocs donné. L'estimateur block_policy est actuellement utilisé, sur la base des données de transactions déjà confirmées ; dans la nouvelle version, mempool_policy y sera ajouté, qui analyse l'état actuel du mempool.
Par défaut, le client utilisera les deux algorithmes et renverra la plus basse des deux estimations. Ainsi, le nouveau mécanisme pourra réduire la commission recommandée après la baisse de charge, mais ne pas l'augmenter par rapport au résultat block_policy.
L'utilisateur pourra sélectionner explicitement l'un des algorithmes via le paramètre fee_rate_estimator. Si le nouvel évaluateur ne dispose pas de données suffisantes, il renverra une erreur. Cela est possible, par exemple, pendant le chargement du pool de mémoire, après avoir reçu un nombre insuffisant de nouveaux blocs ou si son état est considéré comme impropre à une évaluation fiable.
Les développeurs ont également ajouté une prélecture parallèle des données sur les sorties de transaction utilisées (prevouts) lors de la validation des blocs. Par défaut, Bitcoin Core utilise huit threads, avec un maximum de 16. Le paramètre -prevoutfetchthreads=0 désactivera la fonctionnalité.
Le changement devrait accélérer la validation des blocs, principalement dans les situations où les données nécessaires doivent être lues à partir du disque. S'ils sont déjà dans la RAM, l'effet sera moindre.
Un autre changement affectera les transactions Bitcoin partiellement signées (PSBT). Les commandes createpsbt, walletcreatepsbt, converttopsbt et psbtbumpfee créeront par défaut la version 2 du PSBT. Si nécessaire, l'utilisateur peut en sélectionner une autre via l'argument psbt_version.
Les développeurs ont fermé la vulnérabilité
Bitcoin Core 32.0 a également corrigé une vulnérabilité présente dans le client depuis la version 24.0. Cela affectait les systèmes non Windows lors de l'utilisation du paramètre -walletnotify avec l'espace réservé %w. Ce paramètre vous permet d'exécuter automatiquement une commande spécifiée par l'opérateur lorsqu'une transaction liée au portefeuille se produit.
Un utilisateur RPC authentifié ayant le droit de créer des portefeuilles peut spécifier un nom spécialement conçu. Lorsqu'une transaction était notifiée par la suite, les caractères à l'intérieur du nom interrompaient la fuite du shell et, avec le modèle walletnotify approprié, permettaient l'exécution d'une commande supplémentaire au nom du processus Bitcoin Core.
Le problème était dû au fait que la fonction ReplaceAll() transmettait le nom du portefeuille échappé à std::regex_replace() comme texte de remplacement. Les développeurs ont modifié le mécanisme pour que le nom soit traité littéralement.
La vulnérabilité ne peut pas être exploitée via une connexion P2P classique ou sans autorisation. L'attaque nécessitait simultanément un accès RPC avec le droit de créer un portefeuille, walletnotify configuré avec %w et un système d'exploitation autre que Windows.
Problème avec le nouveau serveur HTTP
La branche 32.0 inclut un correctif pour un autre problème de sécurité découvert lors de l'audit d'un nouveau serveur HTTP à l'aide de Kimi K3. Si le serveur traitait déjà une requête, le client pourrait continuer à envoyer des données sans limiter leur taille. Dans certaines conditions, cela a permis une augmentation incontrôlable de la consommation de mémoire du processus.
Les développeurs ont interdit au serveur de lire de nouvelles données du socket pendant que la requête précédente reste en cours de traitement. Dans ce cas, le flux entrant est limité par les mécanismes TCP. Le scénario le plus réaliste nécessitait également un client authentifié pour fonctionner.
Le nouveau serveur HTTP n'a pas encore été utilisé dans les versions stables précédentes de Bitcoin Core. Il sera inclus dans la version 32.0 avec un correctif, ce problème n'a donc pas affecté les nœuds des versions officielles précédentes du client.
De plus, la version 32.0 réduira de plus de moitié l'espace disque de l'index de transactions txindex lorsqu'il sera complètement reconstruit. Les index existants resteront compatibles, mais devront être recréés pour réaliser des économies.
Rappelons qu'en octobre 2025, les développeurs ont sorti Bitcoin Core v30. L'un des principaux changements a été l'augmentation de la limite de données par défaut dans les sorties OP_RETURN de 80 à 100 000 octets.
Vous avez trouvé une erreur dans le texte ? Sélectionnez-le et appuyez sur CTRL+ENTRÉE