Bitcoin Core 32.0 vise une sortie le 10 octobre avec une vérification des blocs plus rapide et des correctifs de sécurité
Points clés
- •Bitcoin Core 32.0 est entré en phase de tests de version candidate lundi, les développeurs visant le 10 octobre pour la version finale, bien que l'issue des tests puisse décaler ce calendrier.
- •La mise à jour accélère la vérification des blocs en lisant les informations de la base de données en parallèle, réduisant la charge de travail des opérateurs de nœuds sans modifier la vitesse de production des blocs par Bitcoin.
- •Un correctif de sécurité empêche des noms de portefeuille forgés de déclencher des commandes sur les systèmes non Windows où un utilisateur authentifié pouvait créer des portefeuilles et où la fonctionnalité walletnotify était configurée pour exécuter des commandes.
- •Le contributeur Matthew Zipkin a découvert une vulnérabilité d'épuisement de mémoire dans le nouveau serveur HTTP de Bitcoin Core en l'auditant avec le modèle d'IA Kimi K3, et la revue a révélé que des requêtes non authentifiées pouvaient également provoquer une croissance de la mémoire lorsque l'interface REST était activée.
- •Après le correctif révisé, 16 connexions non authentifiées ont produit environ 3 Mo de croissance de mémoire sur 90 secondes, contre 3,2 Go auparavant, et le correctif a été fusionné dans Bitcoin Core 32.0 le 5 septembre.

Bitcoin Core 32.0, le logiciel open source qui permet aux ordinateurs de vérifier de manière indépendante les paiements Bitcoin, est entré en phase de tests de version candidate lundi, selon le calendrier du projet. Les versions candidates sont des versions préliminaires publiées afin que les testeurs puissent faire émerger les problèmes restants avant la version finale. Les développeurs visent le 10 octobre pour livrer la version achevée, bien que l'issue des tests puisse encore décaler ce calendrier.
La mise à jour concerne principalement les opérateurs de nœuds et les développeurs qui utilisent le logiciel pour faire fonctionner des portefeuilles et d'autres services, plutôt que les utilisateurs quotidiens d'applications de portefeuille. La performance est un objectif central : selon les notes de version préliminaires, la mise à jour peut accélérer la vérification des blocs en lisant les informations de la base de données en parallèle, sans modifier la vitesse à laquelle Bitcoin produit des blocs. Une vérification plus rapide est importante car la tâche essentielle d'un nœud complet consiste à vérifier chaque nouveau bloc par rapport aux règles du réseau — les blocs arrivent environ toutes les dix minutes — si bien que la réduction de ce travail allège la charge continue de vérification des paiements sans tiers de confiance.
Quatre commandes de portefeuille adopteront également par défaut un nouveau format pour l'échange de transactions partiellement signées entre portefeuilles et dispositifs de signature — un format qui permet à une transaction inachevée de recueillir des signatures sur plusieurs appareils avant d'être complète — bien que les applications puissent toujours demander l'ancienne version si nécessaire.
La sécurité est l'autre priorité de cette version. Un correctif empêche des noms de portefeuille forgés de déclencher des commandes sur l'ordinateur d'un nœud. La faille concernait les systèmes non Windows dans les cas où un utilisateur authentifié pouvait créer des portefeuilles et où la fonctionnalité walletnotify était configurée pour exécuter des commandes lors de transactions de portefeuille. Cette classe de bugs suscite une attention particulière car elle brouille la frontière entre données et instructions : un nom de portefeuille, normalement simple étiquette, pouvait interagir avec l'exécution de commandes de la fonctionnalité walletnotify, et le correctif supprime ce chemin.
Un correctif distinct traite l'utilisation excessive de mémoire dans le nouveau serveur HTTP du projet, qui traite les requêtes des applications connectées. Le contributeur Matthew Zipkin, qui publie sous le pseudonyme pinheadmz, a décrit un « scénario d'épuisement de mémoire » dans sa proposition de correctif. Son évaluation initiale limitait le risque aux clients authentifiés.
Zipkin a déclaré avoir découvert la faille en auditant le nouveau serveur HTTP de Bitcoin Core avec Kimi K3, un modèle d'IA également utilisé par la Bitcoin Red Team pour rechercher des vulnérabilités dans les logiciels Bitcoin. Un correctif antérieur avait traité une partie du problème, a-t-il expliqué, mais un moyen d'épuiser la mémoire disponible d'un ordinateur — une condition « OOM », ou out-of-memory — subsistait.
ant la revue de ce même correctif, l'utilisateur GitHub jeanpablojp a constaté que des requêtes soumises sans identifiants pouvaient également provoquer une croissance de la mémoire lorsque l'interface REST était activée. Après révision du correctif par Zipkin, le relecteur a indiqué que 16 connexions non authentifiées produisaient environ 3 Mo de croissance de mémoire sur 90 secondes, contre 3,2 Go auparavant. Le correctif révisé a été fusionné dans Bitcoin Core 32.0 le 5 septembre dans le cadre des travaux continus visant à améliorer la sécurité du logiciel. Le cas non authentifié a élargi la préoccupation au-delà de la première évaluation, car les requêtes de ce type ne nécessitent aucun utilisateur de confiance connecté.
Ce correctif intervient dans une période plus large de réponse aux vulnérabilités dans les logiciels liés à Bitcoin. Le fabricant de portefeuilles matériels BitBox a corrigé deux failles sévères de firmware en août, sans signaler de preuve d'exploitation. Par ailleurs, les développeurs de Core Lightning, un logiciel de paiement, ont alerté les opérateurs de nœuds sur des vulnérabilités confirmées tout en préparant des correctifs. Les versions candidates d'ici au 10 octobre indiqueront si la date cible est tenue, et les correctifs ne prennent effet que là où les opérateurs exécutent finalement la version mise à jour.