Bitcoin Core 32 Accélère Validation Et Change Les Frais

On ne change pas les règles du jeu, et pourtant le logiciel qui fait tourner une grande partie des nœuds Bitcoin vient d’entrer dans une phase décisive. Le 14 septembre 2026, les mainteneurs ont étiqueté v32.0rc1. Derrière ce numéro un peu administratif se cachent une estimation des frais plus réactive, une validation de blocs qui cesse d’attendre bêtement le disque, et deux correctifs de sécurité qu’il valait mieux trouver avant la version stable. La cible officielle reste le 10 octobre. Rien n’est encore gravé dans le marbre.

Ce Que Change Vraiment Bitcoin Core 32

Beaucoup de lecteurs croient qu’une nouvelle version de Bitcoin Core « met à jour Bitcoin ». Ce n’est pas le cas. Les notes de version provisoires ne touchent pas aux règles de consensus. Un bloc valide avant le reste valide après. Une transaction acceptée par le réseau le reste. Ce que change la 32, c’est le comportement du logiciel : portefeuille, réseau, calcul des frais, performance, surface d’attaque HTTP, format des transactions partiellement signées.

Le projet a gelé les fonctionnalités le 20 août. Le 14 septembre, la branche 32.x a été séparée de la branche principale. Le développement de la 33 a repris de son côté. Le premier candidat de sortie, signé, pointe vers le commit d0231bb, horodaté à 12 h 58 UTC. Un fil de retours dédié aux tests a été ouvert le 15 septembre. Au 16 septembre, aucun binaire final n’existait encore.

Pourquoi Le Calendrier Compte Pour Les Opérateurs

Bitcoin Core ne pousse pas de mise à jour silencieuse. C’est une force et une contrainte. Une force, parce qu’un nœud n’est pas un téléphone grand public : on ne veut pas qu’un binaire non relu s’installe tout seul. Une contrainte, parce que les branches anciennes finissent par sortir du support. L’épisode de la faille CVE-2024-52911, déjà corrigée dans la 29.0 avant que les détails techniques ne deviennent publics, l’a rappelé : quand une branche arrive en fin de vie, le délai de réaction se raccourcit.

Les candidats de sortie existent précisément pour que les opérateurs de nœuds, les développeurs de portefeuilles et les intégrateurs cassent le logiciel dans des conditions réelles. Le projet demande d’utiliser le guide de test spécifique à la candidate, puis de déposer les vrais défauts dans des tickets séparés. Un fil de discussion n’est pas un rapport de bogue. Cette distinction paraît bureaucratique. Elle évite que les régressions se noient dans les commentaires.

Le 10 octobre n’est qu’une cible. Si un correctif tardif s’impose, la date glisse. C’est déjà arrivé. Mieux vaut un retard d’une semaine qu’un serveur HTTP neuf livré avec une fuite mémoire encore ouverte.

L’Estimateur De Frais Ne Se Contente Plus Du Passé

Jusqu’ici, la méthode principale d’estimatesmartfee observait surtout ce qui s’était confirmé dans les blocs récents. Utile, mais un peu myope. Quand la file d’attente se vide soudain, l’historique continue un moment à « se souvenir » des frais élevés. L’utilisateur paie trop cher pour une confirmation qui n’exige plus autant.

La version 32 ajoute un estimateur fondé sur le mempool actuel, c’est-à-dire les transactions encore en attente dans le nœud. Il produit une estimation économique et une estimation conservatrice. Le logiciel vérifie d’abord l’état récent des blocs. S’il juge le mempool trop clairsemé ou malsain, il peut refuser ce second avis.

Quand les deux systèmes donnent un résultat valide, estimatesmartfee conserve le plus bas. Le nouvel estimateur n’a donc pas le droit, dans le mode combiné par défaut, de pousser la recommandation vers le haut. Son rôle est d’abaisser le prix suggéré dès que la file d’attente le permet. Après une période de congestion, c’est précisément ce que beaucoup d’applications attendaient sans le formuler ainsi.

Le mempool raconte le présent. L’historique des blocs raconte la veille. La version 32 accepte enfin de croiser les deux récits, puis de choisir le moins cher lorsqu’ils sont tous les deux crédibles.

Synthèse des notes de version provisoires

Les applications qui veulent l’ancien monde ne sont pas abandonnées. Une option fee_rate_estimator permet de demander block_policy, mempool_policy ou le comportement combiné. Les statistiques du nouvel estimateur vivent dans un fichier séparé, rechargé après redémarrage. Les calculs de frais du portefeuille utilisent le mode combiné. La réponse peut indiquer quel estimateur a tranché. Aux verbosités plus élevées, des indicateurs de « santé » du mempool apparaissent pour les intégrateurs qui en ont besoin.

Cette mécanique n’est pas magique. Un nœud mal connecté, un mempool filtré de manière agressive, une politique locale trop stricte : tout cela peut fausser le tableau. L’estimateur ne voit que ce que ce nœud voit. D’où l’intérêt, pour un service qui facture des frais à des milliers d’utilisateurs, de comparer plusieurs sources et de ne pas traiter la RPC comme une vérité unique.

La Validation Des Blocs Cesse D’Attendre Le Disque

Connecter un bloc, c’est surtout vérifier que chaque entrée dépense bien une sortie existante, non déjà dépensée, et que les scripts tiennent. Ces sorties précédentes, les prevouts, vivent dans la base d’état de la chaîne. Quand elles ne sont pas déjà en cache mémoire, le nœud attend le disque. Sur un disque mécanique, l’attente se voit. Sur un SSD saturé par d’autres lectures, elle se voit aussi.

Bitcoin Core 32 peut désormais précharger ces prevouts pendant que la validation continue, via plusieurs fils de travail. Par défaut, il y en a huit. On peut monter à seize. On peut tout couper en mettant le réglage à zéro. L’option s’appelle -prevoutfetchthreads. Les notes la présentent clairement comme un gain de performance de validation, pas comme une révolution cryptographique.

L’effet dépend du matériel, de la taille du cache, du profil des blocs et de la configuration. Un nœud qui valide surtout des blocs déjà « chauds » en mémoire verra peu de différence. Un nœud qui rattrape de l’historique ou qui traite des blocs denses en entrées inédites devrait moins s’endormir sur les lectures.

Une autre amélioration, plus discrète, concerne AssumeUTXO. Après qu’un nœud démarré depuis un instantané a rattrapé la pointe de la chaîne, getblockchaininfo peut désormais indiquer l’avancement de la validation historique qui continue en arrière-plan. On cesse enfin de deviner si le travail de fond avance ou s’il s’est figé.

Deux Failles Qu’Il Valait Mieux Trouver Maintenant

La première touche la notification de portefeuille hors Windows, dans un scénario étroit. Un utilisateur RPC authentifié, autorisé à créer des portefeuilles, pouvait forger un nom contenant des caractères de substitution alors que le nœud était lancé avec -walletnotify. Dans ces conditions, le nom pouvait déclencher l’exécution de commandes avec les privilèges du processus Bitcoin Core. La 32 traite désormais le nom comme du texte littéral. Elle refuse aussi certains chemins relatifs contenant . ou ...

Ce n’est pas une faille « ouverte à tout Internet ». Il faut déjà un accès RPC authentifié et une option de notification activée. Reste que beaucoup d’installations partagent trop largement cet accès. Un correctif qui transforme une substitution trop généreuse en texte brut est exactement le genre de détail que l’on préfère voir avant la version stable.

La seconde affaire est née pendant la revue du serveur HTTP réécrit, qui remplace libevent dans cette version. Matthew Zipkin a ouvert la pull request #36123 après un audit où le modèle Kimi K3 de Moonshot AI avait signalé un chemin d’épuisement mémoire. Pendant qu’une requête restait occupée, la même connexion pouvait continuer à envoyer et faire mettre en file des données sans limite de taille vraiment efficace.

La première lecture laissait croire qu’il fallait un client authentifié capable de maintenir une requête occupée. Les tests suivants ont montré que le trafic REST, sans authentification, reproduisait le problème. Un relecteur a rapporté que seize connexions REST non authentifiées faisaient passer un processus de test d’environ 46 Mo à près de 3 Go en une minute. Après le correctif révisé, la même épreuve n’augmentait plus la mémoire que d’environ 3 Mo en 90 secondes, contre 3,2 Go avant le correctif.

Le correctif a été fusionné le 5 septembre, donc avant l’étiquette de la candidate. Parce que le serveur HTTP réécrit est nouveau dans la 32, la faille a été attrapée avant d’apparaître dans une version stable. C’est la meilleure version possible d’une mauvaise nouvelle : le défaut existait dans le code neuf, pas encore dans les binaires que le grand public télécharge.

Seize connexions suffisaient à gonfler la mémoire vers trois gigaoctets. Après rustine, la même scène tenait dans une enveloppe de quelques mégaoctets.

Compte rendu de test cité dans les notes

L’usage d’un modèle d’assistance pour la revue s’inscrit dans une tendance plus large. Des équipes de « red team » Bitcoin ont déjà recensé des milliers de pistes sur des projets open source liés à l’écosystème. La plupart exigent une vérification humaine. Ici, la piste a été creusée, reproduite, corrigée, mesurée. C’est le bon ordre.

PSBT Version 2 Devient Le Défaut De Quatre Commandes

Les transactions partiellement signées, ou PSBT, permettent à plusieurs portefeuilles, applications ou dispositifs matériels d’échanger les informations d’une transaction avant diffusion. Quatre commandes changent de défaut : createpsbt, walletcreatepsbt, converttopsbt et psbtbumpfee produisent désormais la version 2. Un argument optionnel psbt_version permet de demander explicitement une autre version supportée.

Ce n’est pas une rupture brutale. L’ancienne version reste demandable. Mais tout logiciel qui suppose, sans le vérifier, que la RPC de Core rendra encore le format précédent devra être relu. Les intégrateurs de coffres matériels, les coordinations multisignatures, les outils de lot : tous sont concernés. Mieux vaut casser cela en candidate qu’en production le 11 octobre.

Le portefeuille gagne aussi exportwatchonlywallet, qui fabrique un fichier de portefeuille descripteur contenant descripteurs publics, historique et carnet d’adresses, sans clés privées. Le tutoriel de signature hors ligne s’appuie désormais sur cette commande pour créer le portefeuille de surveillance en ligne. derivehdkey dérive une clé étendue via un chemin contenant au moins une étape durcie. addhdkey ajoute une clé étendue BIP32 sans générer tout de suite des scripts de sortie.

PrivateBroadcast continue d’être entretenu. Une version précédente avait déjà traité un cas où l’adresse IP d’origine pouvait fuiter. La 32 ajoute d’autres ajustements de RPC et de relais documentés dans les notes provisoires. Ce n’est pas le sujet le plus spectaculaire de la version. C’est le genre de maintenance sans laquelle les fonctions « discrètes » se dégradent à bas bruit.

Ce Que Cette Version Ne Fait Pas

Elle n’augmente pas la taille des blocs. Elle n’introduit pas de nouveau script de consensus. Elle ne « scale » pas Bitcoin à elle seule. Elle ne garantit pas des frais bas : elle propose seulement de mieux lire la file d’attente. Elle ne transforme pas un disque lent en disque rapide : elle masque une partie de la latence par le préchargement.

Elle ne dispense personne de sauvegarder son portefeuille avant mise à jour. Elle ne rend pas un RPC exposé à Internet plus acceptable. Elle ne remplace pas une politique de frais propre à une application métier. Elle ne clôt pas le débat sur la part de nœuds qui tournent encore d’anciennes versions par habitude ou par peur du changement.

Dire cela n’est pas minimiser le travail. C’est éviter le marketing de version qui promet une nouvelle ère à chaque étiquette Git. Bitcoin Core avance par couches. La 32 est une couche de comportement, de performance et d’hygiène.

Comment Tester Sans Mettre En Péril Un Nœud De Production

La candidate n’est pas un binaire de production. On la fait tourner à part. On compare les temps de connexion de blocs. On interroge estimatesmartfee avant et après un creux de mempool. On vérifie que les portefeuilles existants s’ouvrent. On relance les flux PSBT. On survveille la mémoire du processus pendant un trafic REST volontairement bruyant, précisément parce que c’est le scénario qui a fait parler de lui.

Les opérateurs qui exposent l’interface REST devraient traiter cette version comme un rappel : une surface HTTP neuve mérite des limites, un reverse proxy, et l’habitude de ne pas laisser un port de commodité ouvert « parce que ça a toujours marché ». Le correctif réduit le risque décrit. Il ne transforme pas une API de consultation en service public indestructible.

• Isoler la candidate sur une machine ou un conteneur dédié.
• Rejouer les RPC critiques de votre stack, surtout les quatre commandes PSBT.
• Observer la mémoire et les files d’attente disque pendant la validation.
• Documenter le réglage de fils de préchargement retenu.
• Attendre le binaire signé final avant de toucher les nœuds qui sécurisent de l’épargne réelle.

Le Contexte Plus Large Des Outils Bitcoin En 2026

La même année a déjà vu d’autres logiciels Bitcoin confronter des pistes d’épuisement de ressources, parfois après des rapports assistés par des modèles. Core Lightning, par exemple, a confirmé des défauts après revue humaine et a demandé aux opérateurs de mettre à jour ou de passer temporairement hors ligne. Le motif se répète : la complexité des daemons, des API et des formats d’échange crée des recoins. Les recoins se découvrent plus vite quand davantage d’yeux, humains ou assistés, lisent le code. Ils ne se ferment que lorsque quelqu’un mesure, corrige et fusionne.

Bitcoin Core reste le client de référence le plus scruté. Ce statut n’interdit pas les erreurs. Il augmente la probabilité qu’elles soient vues avant la diffusion large. La réécriture HTTP de la 32 est un bon exemple : changer une brique ancienne introduit un risque neuf, mais offre aussi une revue neuve. Le calendrier de candidate existe pour que ce risque neuf ne se transforme pas en incident de production.

Les utilisateurs finaux qui ne font que payer un café en bitcoin ne verront peut-être rien. Les portefeuilles qui s’appuient sur estimatesmartfee pourront, dans certaines fenêtres de marché, proposer des frais un peu moins pessimistes. Les nœuds qui valident beaucoup pourront gagner des secondes ici et là. Les intégrateurs PSBT devront lire les notes. Les admins qui laissent REST ouvert devront relire leur exposition. Quatre publics, quatre lectures de la même version.

Une Mise En Perspective Sur Les Frais

Les frais Bitcoin ne sont pas un tarif administratif. Ce sont une enchère pour un espace limité. Un estimateur n’invente pas de capacité. Il tente de lire la tension. L’ancienne lecture, trop ancrée dans les blocs déjà minés, avait un défaut de latence psychologique : elle restait chère un peu trop longtemps. La nouvelle lecture, ancrée dans la file, a un défaut inverse possible : elle peut devenir trop optimiste si le mempool local n’est pas représentatif.

Le mode combiné, en prenant le minimum des deux avis valides, choisit délibérément le biais « ne pas trop faire payer » plutôt que le biais « ne surtout pas rater la confirmation ». Les applications qui doivent absolument entrer dans le prochain bloc continueront d’avoir besoin d’une politique plus agressive. Rien n’empêche de demander block_policy ou d’ajouter une marge. La 32 donne un levier. Elle ne décide pas à la place du métier.

On peut s’attendre à des captures d’écran, dès les premiers jours de test, montrant des recommandations plus basses juste après une vidange de mempool. On peut aussi s’attendre à des fils de discussion où un service constate l’inverse sur un nœud mal pairé. Les deux observations peuvent être vraies en même temps. C’est le propre d’un estimateur local.

Performance : Ce Qu’Il Faut Mesurer Vraiment

Parler de « validation plus rapide » sans chiffre de production est tentant et insuffisant. Le préchargement réduit l’attente disque. Il n’accélère pas la vérification cryptographique elle-même. Sur une machine où le goulot est le processeur, le gain sera mince. Sur une machine où le goulot est un volume saturé d’entrées-sorties aléatoires, le gain peut être visible.

Les opérateurs sérieux noteront le temps entre réception et connexion, la profondeur de cache, le type de stockage, le nombre de fils, et le profil des blocs de la période de test. Ils éviteront de conclure après trois blocs. Ils éviteront aussi de monter à seize fils sur une machine à quatre cœurs déjà occupée par l’indexation. Le défaut de huit est un compromis, pas une vérité universelle.

AssumeUTXO, de son côté, n’accélère pas la validation au sens strict : il change l’ordre dans lequel on fait confiance puis on vérifie. Afficher la progression du travail de fond évite surtout l’angoisse opérationnelle. Un nœud qui a l’air « à jour » alors que l’historique n’est pas encore entièrement relu n’est pas un nœud fini. Pouvoir le lire dans getblockchaininfo est une question de clarté, pas de magie.

Sécurité : Authentifié N’Est Pas Inoffensif

Le scénario -walletnotify rappelle une leçon ancienne : les caractères de substitution dans les noms fournis par un utilisateur sont une source classique d’accidents. Traiter le nom comme du texte littéral est la réponse saine. Restreindre les chemins relatifs l’est aussi. Windows n’était pas dans le périmètre décrit, ce qui ne signifie pas que les nœuds Windows n’ont rien à relire : cela signifie seulement que le défaut documenté visait un autre socle.

Le scénario REST rappelle une autre leçon : « pas d’authentification » n’égale pas « pas de danger ». Une API de lecture peut encore faire gonfler la mémoire. Limiter la taille, limiter les connexions, limiter ce que l’on expose, rester les trois réflexes. Le fait que le défaut ait été trouvé avant la version stable est un succès de processus. Le fait qu’il ait existé dans le code neuf est un rappel que les réécritures coûtent.

Les opérateurs qui croient n’être concernés que s’ils « ont des ennemis » se trompent de modèle. Un balayage Internet, un script mal écrit, un partenaire trop curieux suffisent. On configure d’abord comme si la curiosité était la norme. On relâche ensuite, éventuellement, derrière un réseau privé.

Portefeuilles, Descripteurs Et Signature Hors Ligne

Exporter un portefeuille de surveillance sans clés privées paraît un détail d’interface. C’est en réalité le geste que beaucoup de tutoriels bricolent encore à la main. Avoir une RPC dédiée réduit les erreurs de copie, les descripteurs incomplets, les carnets d’adresses oubliés. Le tutoriel officiel qui s’aligne dessus est un signal : le flux recommandé n’est plus un assemblage de commandes disparates.

Dériver une clé étendue avec au moins une étape durcie, ajouter une clé sans générer tout de suite des scripts : ces commandes parlent aux intégrateurs plus qu’au particulier. Elles rendent le portefeuille descripteur un peu plus programmable. Elles n’exemptent personne de comprendre ce qu’est une étape durcie, ni pourquoi l’on sépare parfois la possession d’une xpub et la génération immédiate d’adresses.

Dans un écosystème où les dispositifs matériels, les coordinations et les politiques de dépense se multiplient, ces petites RPC sont le vrai produit. La 32 n’invente pas le descripteur. Elle rend un peu moins pénible de vivre avec.

Ce Que Les Médias Racontent Trop Vite

Le titre facile dira que Bitcoin Core 32 « change les frais ». Non. Il change la manière dont le logiciel recommande un tarif. Le titre facile dira que la validation est « révolutionnée ». Non. Elle précharge mieux. Le titre facile dira que l’intelligence artificielle a « sauvé Bitcoin ». Non. Un modèle a signalé un chemin ; des humains ont reproduit, discuté, patché, mesuré, fusionné.

Le titre juste est plus plat, et plus vrai : le client de référence entre en candidate avec un estimateur mixte, un préchargement parallèle des prevouts, un serveur HTTP neuf déjà rustiné, un défaut de notification refermé, et un défaut de format PSBT à anticiper côté applications. Plat, mais actionnable.

Les comptes qui relaient l’annonce le 16 septembre n’ont pas tort de parler de test final. Ils ont tort s’ils parlent de sortie accomplie. Tant que le binaire stable n’est pas étiqueté, la 32 reste une hypothèse bien avancée, pas une norme installée.

Vers Le 10 Octobre, Sans Magie

Le fil de retours ouvert le 15 septembre doit servir à quelque chose. Si les testeurs se taisent, les mainteneurs n’auront que leurs propres machines. Si les testeurs crient pour des préférences cosmétiques, le signal utile se noie. Le projet a été clair : les vrais défauts vont dans des tickets dédiés. C’est moins glamour qu’un fil unique. C’est plus efficace.

D’ici la cible d’octobre, d’autres rustines peuvent encore entrer, du moment qu’elles restent dans l’esprit du gel : corriger, pas relancer le chantier. La branche 33 avance ailleurs. Cette séparation est saine. Elle évite que l’envie de la prochaine idée ne retarde la version que les opérateurs attendent maintenant.

Quand le binaire final paraîtra, chacun restera libre de ne pas l’installer tout de suite. Cette liberté est le modèle. Elle implique aussi une responsabilité : connaître sa version, connaître sa surface HTTP, connaître sa politique de frais, connaître ses flux PSBT. Bitcoin Core 32 ne rend pas ces questions obsolètes. Elle les rend un peu plus précises.

En attendant, le geste le plus raisonnable n’est pas l’enthousiasme ni le refus. C’est le banc d’essai. Faire tourner la candidate. Lire les notes jusqu’au bout. Vérifier ce qui casse chez soi. Puis, seulement ensuite, décider de la date à laquelle le nœud qui compte vraiment passera de l’autre côté.