Bitcoin Core 32.1 est sorti le 27 octobre 2026 : pourquoi 32.0 a été retirée, les trois bugs divulgués et le nouvel estimateur de frais

1. Qu'est-ce que Bitcoin Core 32.1, et pourquoi n'y a-t-il pas de 32.0 ?

Bitcoin Core est l'implémentation de référence de Bitcoin, le logiciel qui valide les blocs, relaie les transactions et fait tourner le wallet derrière de nombreux services. Il publie une version majeure environ tous les six mois et maintient les trois plus récentes. La version 32.1, publiée le 27 octobre 2026, est la première release publique de la branche 32.x, avec un nouvel estimateur de frais, des valeurs par défaut de connexion plus élevées, un index des transactions plus compact, la version 2 des PSBT par défaut dans les RPC du wallet et une série de correctifs de sécurité. Elle ne change aucune règle de consensus : les blocs et les transactions valides avant le restent après.

32.0 n'existe que sous forme de tag. Le mainteneur fanquake l'a taguée le 21 octobre et a écrit dans l'issue du calendrier des releases, le 26 octobre, qu'en raison de problèmes de dernière minute, 32.0 ne serait ni annoncée ni publiée et qu'aucun binaire ne serait mis en ligne ; 32.1 suivrait avec le même contenu plus des correctifs supplémentaires. La pull request qui a finalisé 32.1, fusionnée l'après-midi même, rétroporte exactement trois changements d'Antoine Poinsot : la surveillance des exceptions de socket alignée entre les backends poll et select, un délai d'expiration de 20 minutes pour les pairs dont le tampon d'envoi ne se vide jamais, et des positions sur 64 bits dans les fichiers de blocs et les fichiers undo. Ce sont les correctifs des trois vulnérabilités divulguées deux jours plus tard, décrites dans la section 3. Le projet n'en a pas dit davantage sur les raisons.

2. Quand est-elle sortie ? Les dates clés

Les dates viennent de l'issue du calendrier des releases de Bitcoin Core, du serveur de téléchargement de bitcoincore.org et des billets de divulgation. Statut au 1 novembre 2026.

3. Quelles vulnérabilités ont été corrigées et divulguées ?

Trois, toutes publiées le 28 octobre 2026 et toutes trouvées par la même voie : une analyse automatisée du code par un grand modèle de langage, menée sous le nom de Project Loupe par Elias Rohrer chez Spiral, Gregory Sanders validant chaque découverte et la signalant à l'équipe sécurité de Bitcoin Core. Deux ont été redécouvertes indépendamment par d'autres chercheurs avant la sortie des correctifs. La politique de Bitcoin Core est de divulguer les bugs qu'il juge faciles à découvrir dès que des versions corrigées existent pour chaque branche maintenue, d'où des comptes rendus publiés un jour après 32.1.

CVE-2026-117349, gravité moyenne : un pair qui prétend ne pas gérer les pings BIP 31 n'est jamais déconnecté pour les avoir ignorés, et s'il lit aussi les messages très lentement, le nœud continue de lui mettre en file des annonces de transactions sans limite. Le billet chiffre la croissance à environ 2 Mo par heure au maximum pour un pair entrant et 5 Mo par heure pour un pair sortant ; les nœuds qui tournent avec blocksonly sont bien moins exposés. Signalée le 15 septembre, corrigée par la pull request #36667, qui déconnecte un pair en pause qui n'a pas vidé son tampon d'envoi en 20 minutes.

CVE-2026-117350, gravité moyenne, ne touche que Windows, macOS et BSD : le code de socket fondé sur select vérifiait les conditions exceptionnelles même quand les lectures étaient suspendues pour contre-pression, si bien qu'un pair envoyant des données urgentes TCP pouvait forcer des lectures qui contournent la limite mémoire par pair jusqu'à ce que le nœud manque de mémoire. Linux utilise poll et n'est pas concerné. Signalée le 23 octobre, trois jours avant la fusion des correctifs, et corrigée par la pull request #36665.

CVE-2026-117346, gravité faible : les positions dans les fichiers de blocs et les fichiers undo étaient sur 32 bits, si bien qu'une fois un fichier undo au-delà de 4 Gio, les nouvelles données écrasaient les anciennes, et une reorg ultérieure ayant besoin de ces données arrêtait le nœud jusqu'à une réindexation sur une version corrigée. Sur Windows et les systèmes 32 bits, les écritures échouent au-delà de 2 Gio. Le billet juge l'exploitation impraticable sur les systèmes 64 bits : un mineur aurait besoin de plusieurs milliers de blocs de transactions non standard, environ un mois de blocs, placés avec précision, plus une reorg spécifique de deux blocs. Signalée pour la première fois le 8 juillet, corrigée par la pull request #36669, qui stocke les positions sous forme d'entiers 64 bits sans changer le format sur disque ; les systèmes 32 bits restent concernés.

Les notes de version de 32.1 listent d'autres correctifs qui ne sont pas des CVE : une nouvelle tentative de diffusion privée qui pouvait révéler l'IP de l'expéditeur en contournant le proxy Tor, un chemin d'exécution de commandes via des noms de wallet forgés avec walletnotify sur les systèmes autres que Windows, et des plafonds de 10 000 transactions en diffusion privée en file d'attente et de 1 000 tentatives d'envoi chacune. Les notes indiquent aussi que dans deux semaines le projet divulguera trois vulnérabilités de gravité moyenne et élevée corrigées dans 30.0 (et aucune de gravité faible dans 32.1), donc un autre billet de divulgation est attendu autour du 10 novembre.

4. Comment le nouvel estimateur de frais change-t-il les frais que vous payez ?

Si vous utilisez un wallet ou un service qui demande des frais à un nœud Bitcoin Core via estimatesmartfee, 32.1 change ce qu'il entend. Jusqu'ici, Core n'utilisait que son estimateur fondé sur les blocs (block policy), qui regarde en arrière les tarifs des transactions confirmées dans un nombre de blocs cible. Il est prudent et lent à redescendre : après un pic de congestion, il continue de proposer des tarifs élevés pendant un moment parce que l'historique dit toujours « élevé ». 32.1 ajoute un estimateur fondé sur la mempool (mempool policy), qui regarde ce qui attend en ce moment, et estimatesmartfee renvoie la plus basse des deux valeurs. L'estimateur de mempool ne peut que baisser le résultat, jamais le relever, donc un wallet basé sur Core cesse de surpayer plus tôt une fois les blocs dégagés, et se comporte comme avant quand la mempool est pleine.

La même idée est à l'origine des tarifs qu'affichent la plupart des explorers. Au 1 novembre 2026, mempool.space, qui estime à partir de la seule mempool, place l'objectif à une demi-heure à 1 sat/vB, soit $0.11 pour un transfert classique avec un BTC à 77 731 $US :

Les tarifs Bitcoin en ce moment (mempool.space)

Pour les développeurs, la commande RPC gagne un objet d'options : fee_rate_estimator accepte auto (la valeur par défaut, combinée), block_policy (l'ancien comportement) ou mempool_policy, les valeurs inconnues sont rejetées, la verbosité 2 ajoute mempool_health_statistics, et en mode auto la réponse nomme l'estimateur utilisé. Les données de l'estimateur block policy sont déplacées vers fees/block_policy_estimates.dat et migrées au premier démarrage. La sélection des pièces du wallet utilise l'estimation combinée. Ce que cela ne change pas : les frais restent votre choix, le replace-by-fee et le child-pays-for-parent sauvent toujours une transaction qui a payé trop peu, et les paliers sat/vB de notre guide des frais se rafraîchissent chaque minute depuis la mempool.

5. Qu'est-ce qui change pour les opérateurs de nœuds ?

Mettez à jour, et vérifiez sur quelle branche vous êtes. 29.x a atteint sa fin de vie le 27 octobre 2026 et 29.5, du 28 octobre, est sa dernière release, donc un nœud sur 29.x ne recevra plus aucun correctif ; 30.x reste maintenue jusqu'à la sortie de 33.0, 31.x jusqu'à 34.0 et 32.x jusqu'à 35.0. Passer directement d'une version en fin de vie à 32.1 est pris en charge, même si la migration du répertoire de données peut prendre du temps. Les plateformes prises en charge sont Linux avec un noyau 3.17 ou plus récent, macOS 14 ou plus récent et Windows 10 version 1903 ou plus récent.

Deux valeurs par défaut changent l'empreinte de votre nœud. Le maxconnections par défaut passe de 125 à 200, et une nouvelle option inboundrelaypercent (50 par défaut) plafonne la part des slots entrants accordés aux pairs qui relaient des transactions ; pour conserver l'ancien comportement, lancez avec maxconnections=125 et inboundrelaypercent=100. Le relais des transactions sortantes est désormais limité en débit avec une file d'attente globale (txsendrate, 14 transactions par seconde par défaut, 2,5 fois plus pour les pairs sortants, plus un plafond de bande passante de 12 Mo par 10 minutes). Les services cachés Tor créés automatiquement reçoivent des défenses par preuve de travail quand le démon Tor les prend en charge. Le serveur RPC n'utilise plus libevent, et une nouvelle option rpcmaxconnections (16 par défaut) limite le nombre de clients HTTP simultanés.

Deux options économisent du disque et du temps. L'index des transactions stocke moins de données : un txindex reconstruit occupe moins de la moitié de l'espace, mais vous n'obtenez ce gain qu'en supprimant indexes/txindex dans le répertoire de données et en redémarrant, ce qui peut prendre des heures ; le txospenderindex rétrécit de la même façon. La validation des blocs précharge les sorties précédentes en parallèle avec prevoutfetchthreads, 8 par défaut, 16 au maximum, 0 pour désactiver. Les anciennes sessions I2P ElGamal seront supprimées d'ici v34 et la prise en charge de CJDNS est en cours de réexamen, donc les opérateurs qui dépendent de l'un ou de l'autre devraient suivre les prochaines notes de version.

6. Qu'est-ce qui change pour les développeurs et les wallets ?

Le changement incompatible, c'est la version 2 des PSBT. createpsbt, walletcreatefundedpsbt, converttopsbt et psbtbumpfee produisent désormais des PSBT version 2 par défaut ; un nouvel argument psbt_version sélectionne la version 0 pour les outils qui ne savent pas encore analyser la v2. Si un appareil de signature, un coordinateur ou un script de votre flux n'a pas été testé avec PSBTv2, passez l'argument avant de mettre à jour le nœud auquel il parle.

Plusieurs champs et options sont dépréciés : vsize dans les RPC de mempool et getrawtransaction (utilisez vsize_adjusted, ou vsize_bip141 pour la taille BIP 141 brute), l'option de démarrage walletrbf et la clé bip125-replaceable (les nœuds relaient les remplacements de n'importe quelle transaction depuis Core 28), et la commande RPC removeprunedfunds, qui exige désormais deprecatedrpc=removeprunedfunds. Les noms de wallet comportant des éléments de chemin faits de points, ou un wallet nommé d'une simple barre oblique, sont rejetés.

Nouveautés côté RPC : exportwatchonlywallet, addhdkey et derivehdkey ; send et sendall ne sont plus marqués expérimentaux ; getblockchaininfo rapporte la progression de la validation en arrière-plan d'assumeutxo ; getbalances ajoute un solde nonmempool ; getnetworkinfo rapporte la version de l'asmap ; exportasmap et getopenrpcinfo ; une commande bitcoin-util getchainparams. Le serveur HTTP maison est plus strict sur les en-têtes, donc vérifiez tout client qui en envoie d'inhabituels. Rien de tout cela ne touche à la façon dont une transaction est construite ou diffusée, donc les SDK qui parlent à un nœud via l'interface RPC standard, dont ChainGate, continuent de fonctionner.

7. Les utilisateurs de Bitcoin doivent-ils faire quelque chose ?

Non. 32.1 ne change aucune règle de consensus, donc pas de fork, pas de nouveau coin et rien à migrer ; vos clés, vos adresses et vos soldes sont les mêmes. Si vous utilisez un wallet léger ou gardez vos coins sur un exchange, la mise à jour se fait sur les machines d'autres personnes.

Ce que vous pourrez remarquer, c'est un wallet connecté à un nœud Core qui propose des frais plus bas dans les heures qui suivent une période chargée, puisque l'estimateur lit désormais la mempool. Si vous faites tourner votre propre nœud, mettez à jour ; si vous êtes sur 29.x, vous êtes sur une branche non maintenue depuis le 27 octobre. Quiconque vous dit de déplacer ou de « mettre à jour » vos bitcoins à cause d'une release de Core tente une arnaque.

8. Qu'est-ce qui est confirmé et qu'est-ce qui reste ouvert ?

9. Que vient-il ensuite ?

Le prochain élément daté est la divulgation des trois vulnérabilités corrigées dans 30.0, que les notes de version promettent deux semaines après la release, donc autour du 10 novembre 2026. Nous l'ajouterons ici, avec toute version de maintenance 32.x. Le journal des mises à jour ci-dessous indique ce qui a changé et quand.

En attendant, le guide des frais Bitcoin affiche les paliers sat/vB en direct que le nouvel estimateur est en train de rattraper, le guide sur les hash de transaction explique comment suivre une transaction en attente, et l'article sur la fermeture de Binance Pool couvre ce qui arrive aux transactions bloquées une fois que cet accélérateur ferme le 10 novembre.

Mises à jour de cet article

• 31 octobre 2026 : première publication. Dates tirées de l'issue du calendrier des releases de Bitcoin Core, du serveur de téléchargement et des pages de release de bitcoincore.org ; détails des vulnérabilités tirés des trois billets de divulgation du 28 octobre ; contenu de la release tiré des notes de version de 32.1 et de la page du cycle de vie.

Questions fréquentes