Bitcoin Core 32.0 entre en phase finale avant sa sortie prévue le 10 octobre

Bitcoin Core 32.0 arrive au bout d’un cycle de développement où les changements les plus visibles ne sont pas forcément les plus intéressants. La version candidate est désormais disponible et les développeurs visent le 10 octobre pour la mouture finale. Au menu : validation mieux organisée, serveur HTTP revu et plusieurs correctifs de sécurité. Un audit assisté par IA a aussi lancé une séquence de tests assez instructive : le premier diagnostic n’avait pas encore raconté toute l’histoire.

Bitcoin Core 32.0 accélère surtout le travail sous le capot

Bitcoin Core permet à un ordinateur de vérifier lui-même les transactions et les blocs du réseau, sans devoir déléguer cette tâche à un service extérieur. La version 32.0 touche donc surtout les opérateurs de nœuds, les développeurs et les services bâtis autour de cette infrastructure.

Le changement de performance le plus parlant concerne la validation des blocs. Pour vérifier une transaction, le logiciel doit notamment retrouver les sorties antérieures qu’elle dépense, les fameux prevouts. Lorsqu’elles se trouvent sur disque, leur lecture peut ralentir le travail. La nouvelle version permet de précharger ces données en parallèle depuis la base chainstate.

Huit threads travaillent par défaut, avec un maximum fixé à seize. Une machine plus modeste pourra ramener ce nombre à zéro et désactiver le mécanisme.

Le gain ne rendra pas la blockchain plus rapide et ne réduira pas l’intervalle entre deux blocs. Il concerne le travail effectué localement par le nœud. Une nuance technique, certes discrète à l’écran, mais plutôt concrète pour ceux qui entretiennent l’infrastructure jour après jour.

Kimi K3 repère une faille, les développeurs creusent davantage

L’histoire commence avec Matthew Zipkin, contributeur connu sous le pseudonyme pinheadmz. En auditant le nouveau serveur HTTP avec Kimi K3, un modèle d’intelligence artificielle également employé par la Bitcoin Red Team, il tombe sur un scénario d’épuisement de mémoire.

Le serveur pouvait continuer à lire les données envoyées par un client alors qu’il traitait déjà une requête. Un client malveillant avait ainsi la possibilité de maintenir cette requête occupée puis d’envoyer toujours davantage de données. Celles-ci s’accumulaient en mémoire.

Zipkin pensait d’abord que l’attaque nécessitait une authentification. Puis la revue du code a changé le tableau. Le développeur jeanpablojp teste l’interface REST et constate que 16 connexions sans identifiants peuvent faire passer la consommation du nœud d’environ 46 Mo à près de 3 Go en une minute.

L’IA avait donc bien repéré un problème. Elle n’avait pas clos l’enquête. Un humain a poussé le test plus loin et découvert un vecteur plus large. Voilà une collaboration homme-machine autrement plus intéressante qu’un simple match visant à savoir lequel des deux trouve le plus de bugs.

Le premier correctif ralentissait trop le serveur

La première réponse de Zipkin suivait une logique assez sobre : lorsqu’une requête est déjà traitée, inutile de continuer à aspirer les données suivantes dans la mémoire de l’application. Elles peuvent patienter côté système jusqu’à ce que la pression TCP freine naturellement l’expéditeur.

La solution de ce patch consiste à ne même plus lire le socket lorsque nous sommes occupés à traiter une requête.

Matthew Zipkin, GitHub PR #36123

Seulement, le premier patch avait un défaut. Sur une connexion persistante, jeanpablojp mesure une latence médiane passant d’environ 0,14 ms à 53 ms. Le correctif protégeait la mémoire, mais faisait attendre inutilement certaines requêtes.

Nouvelle copie, nouveaux tests. Après révision, 16 connexions REST non authentifiées n’ajoutent plus qu’environ 3 Mo en 90 secondes, contre 3,2 Go auparavant. La pénalité d’environ 50 ms disparaît également.

Tout n’est pas gratuit pour autant. Sur un nœud inactif soumis à un pipelining continu, un reviewer mesure un débit passant de 383 à 18,9 requêtes par seconde. Un cas très spécifique, qu’il dit ne retrouver chez aucun client réel. La sécurité gagne donc nettement la mise, avec un compromis mesuré plutôt que caché.

En octobre, les opérateurs trouveront surtout du ménage utile

La mouture 32.0 ne se résume pas à cette histoire de mémoire. Plusieurs changements moins spectaculaires arriveront avec elle si le calendrier tient. Quatre commandes liées aux transactions partiellement signées utiliseront PSBT v2 par défaut. Les applications qui en ont besoin pourront encore demander l’ancienne version.

Le serveur HTTP, lui, a été réécrit pour remplacer libevent. Il applique des règles plus strictes et limite par défaut à seize le nombre de clients HTTP connectés simultanément. Autre économie appréciable : après reconstruction, l’index des transactions txindex occupera moins de la moitié de son ancien espace disque.

Côté portefeuille, exportwatchonlywallet permettra d’exporter les informations nécessaires à un portefeuille d’observation sans emporter les clés privées.

Un correctif ferme aussi la faille walletnotify. Sur les systèmes autres que Windows, un utilisateur RPC authentifié disposant des droits requis pouvait fabriquer certains noms de portefeuilles afin de provoquer l’exécution de commandes. Ces noms sont désormais traités littéralement.

Pour l’utilisateur d’une application légère, rien de tout cela ne bouleverse la journée. Pour ceux qui font tourner les nœuds de la blockchain, les détails comptent davantage.

À retenir avant le 10 octobre

• La sortie de Bitcoin Core 32.0 vise le 10 octobre 2026, une échéance qui reste susceptible de bouger durant les derniers tests de la version candidate.
• La validation pourra précharger certaines données avec huit threads par défaut et seize au maximum, sans modifier la cadence de production des blocs.
• Après correction, 16 connexions REST non authentifiées ajoutaient environ 3 Mo de mémoire en 90 secondes, contre 3,2 Go avant la révision.
• Quatre commandes de portefeuille adopteront PSBT v2 par défaut, tandis que les applications conserveront la possibilité de demander la version précédente.
• Un txindex entièrement reconstruit prendra moins de la moitié de l’espace disque, tandis que le nouveau serveur HTTP reçoit plusieurs garde-fous supplémentaires.

Le calendrier offre d’ailleurs un joli croisement. Tandis que Bitcoin Core vise octobre, Ethereum prépare Glamsterdam, prochaine évolution majeure de sa blockchain. Sepolia doit accueillir un test le 6 octobre, si les bugs encore présents sur les devnets sont corrigés. Le mainnet reste attendu au quatrième trimestre, avec décembre encore possible. Deux chantiers différents, une même méthode : tester, casser parfois, corriger beaucoup, puis seulement livrer.