Bitcoin Core 32 : mettre à jour son nœud

Par Louis T. · Mis à jour le 24 octobre 2026

Bitcoin Core, le logiciel qui fait tourner la grande majorité des nœuds du réseau Bitcoin, s'apprête à passer en version 32.0. La version a été étiquetée le 21 octobre 2026 selon crypto.news, et ses notes de version sont figées. Le même jour ou presque, le 22 octobre, les développeurs ont changé la façon dont ils publient les failles de sécurité : certaines seront désormais corrigées et rendues publiques sans attendre un an.

Le timing n'est pas anodin. D'après un relevé du réseau publié par CryptoSlate, 43,6 % des nœuds Bitcoin Core visibles tournent déjà sur une version qui ne reçoit plus de correctifs. Avec la sortie de la 32.0, ce chiffre grimpera mécaniquement au-dessus de 50 %. Les détenteurs de bitcoins n'ont rien à faire ; ceux qui font tourner un nœud chez eux, pour miner en solo ou vérifier leurs propres transactions, ont en revanche quelques réglages à contrôler.

Où en est la version 32.0

Bitcoin Core sort une version majeure tous les six mois environ : la 30.0 le 10 octobre 2025, la 31.0 le 19 avril 2026. La 32.0 était visée pour le 10 octobre 2026, mais la phase de test a duré plus longtemps que prévu, avec quatre versions candidates (la dernière, rc4, date du 14 octobre). Au soir du 24 octobre, le site officiel bitcoincore.org ne propose toujours que ces versions de test dans son dossier 32.0, et sa page de cycle de vie affiche une date de sortie « TBA ». Les fichiers définitifs devraient donc arriver dans les prochains jours.

Ce détail compte, car la règle de maintenance est simple : seules les trois dernières versions majeures reçoivent des correctifs. Le jour où la 32.0 sera publiée, la branche 29.x passera en « fin de vie », comme les notes de version l'annoncent noir sur blanc.

Ce qui change concrètement dans Bitcoin Core 32

Première chose à savoir : cette version ne modifie aucune règle de consensus. Pas de soft fork, pas de risque de scission de la chaîne. Les changements portent sur les performances, les frais, le réseau et le portefeuille intégré.

Des estimations de frais qui baissent plus vite

Jusqu'ici, la commande estimatesmartfee calculait les frais en regardant les blocs déjà minés. Problème : après un pic de congestion, elle restait chère plusieurs heures alors que le mempool s'était vidé. La 32.0 ajoute un second estimateur qui lit directement les transactions en attente. Le logiciel garde le plus bas des deux résultats, ce qui veut dire que le nouvel estimateur ne peut que faire baisser la recommandation, jamais la monter. Le portefeuille intégré l'utilise par défaut. Si vous préférez l'ancien comportement, l'option fee_rate_estimator accepte "block_policy".

Validation plus rapide, plus de connexions

Pendant la vérification d'un bloc, le nœud doit relire sur le disque les sorties de transactions dépensées. Il peut maintenant le faire en parallèle, sur 8 fils d'exécution par défaut (jusqu'à 16 avec -prevoutfetchthreads, 0 pour désactiver). Le gain se sentira surtout lors d'une synchronisation ou d'un rattrapage après une coupure, sur un disque lent. Les notes de version ne chiffrent pas l'accélération.

Le nombre maximal de connexions automatiques passe de 125 à 200. Les places supplémentaires servent aux pairs qui ne relaient que des blocs : les pairs qui échangent des transactions restent limités à 50 % des connexions entrantes (nouvelle option -inboundrelaypercent). Sur une petite box avec une connexion modeste, c'est un réglage à surveiller.

Autre bonne nouvelle pour ceux qui activent -txindex : l'index des transactions reconstruit à neuf prend moins de la moitié de la place sur le disque.

Deux failles fermées avant d'avoir servi

La 32.0 remplace libevent, la bibliothèque qui gérait jusqu'ici le serveur web interne du nœud, par un serveur maison. Pendant les tests, une faille d'épuisement de la mémoire y a été trouvée : selon CoinDesk, 16 connexions non authentifiées à l'interface REST faisaient grimper la mémoire d'un nœud de 46 Mo à environ 3 Go en une minute. Corrigée avant la sortie, elle n'a jamais touché une version stable. Une nouvelle option, -rpcmaxconnections, limite à 16 le nombre de clients HTTP simultanés.

La seconde faille existait, elle, depuis Bitcoin Core 24.0 : hors Windows (Linux, macOS), un nom de portefeuille fabriqué avec des caractères spéciaux pouvait exécuter des commandes sur la machine si l'option -walletnotify était active. Il fallait déjà disposer d'un accès authentifié à l'interface RPC avec le droit de créer des portefeuilles, ce qui limite beaucoup le risque.

PSBT v2 par défaut : attention aux multisigs

C'est le changement le plus susceptible de casser quelque chose. Les PSBT (Partially Signed Bitcoin Transactions) sont le format utilisé pour faire circuler une transaction non signée entre plusieurs outils : un nœud qui la prépare, un portefeuille matériel qui la signe, un deuxième signataire dans un multisig. Quatre commandes (createpsbt, walletcreatefundedpsbt, converttopsbt et psbtbumpfee) produisent désormais des PSBT en version 2 au lieu de la version 0.

Selon CryptoSlate, un utilisateur a signalé le 14 octobre que des fichiers créés par la nouvelle interface graphique ne s'importaient pas dans un co-signataire équipé d'une version plus ancienne de Bitcoin Core. La correction est repoussée à la 32.1. En pratique, si vous signez avec un autre logiciel ou un autre appareil, testez la chaîne complète sur un petit montant avant de déplacer une somme importante. En ligne de commande, l'argument psbt_version permet de redemander l'ancien format.

Pour les adeptes de la signature hors ligne, la 32.0 apporte aussi un outil pratique : exportwatchonlywallet (ou le menu équivalent de l'interface) crée une copie en lecture seule d'un portefeuille, sans aucune clé privée, à installer sur la machine connectée. Les clés restent sur l'ordinateur hors ligne ou sur le portefeuille froid.

La nouvelle règle de publication des failles

Bitcoin Core classe chaque faille signalée en quatre niveaux : critique, haute, moyenne et basse. Jusqu'au 22 octobre, une faille moyenne ou haute restait secrète jusqu'à deux semaines après la fin de vie de la dernière version touchée, soit environ un an après sa correction. L'exemple type est CVE-2024-52911, un bug qui permettait de faire planter un nœud avec un bloc piégé : corrigé dans la 29.0 en avril 2025, il n'a été rendu public qu'en mai 2026.

La politique publiée sur bitcoincore.org ajoute désormais une voie rapide pour les failles jugées « facilement découvrables », c'est-à-dire qu'un tiers pourrait retrouver avec un effort minimal grâce aux outils d'analyse automatique actuels. Pour celles-là, les développeurs publieront dès que possible une version corrective de chacune des trois branches maintenues, accompagnée d'un avis de sécurité, sans période d'embargo. Les autres failles gardent l'ancien calendrier, et les failles critiques restent traitées au cas par cas.

Le raisonnement d'Antoine Poinsot, qui a porté la proposition : quand une faille est simple à trouver, la cacher protège peu et retarde surtout la sortie du correctif. Antoine Riard, un autre développeur, a objecté qu'un avis trop vague pourrait pousser des opérateurs non concernés à mettre à jour dans la précipitation. Les deux points de vue sont rapportés par crypto.news et CryptoSlate. Conséquence directe pour vous : des versions correctives (32.0.1, 31.x…) pourraient tomber sans prévenir, et il faudra les installer vite.

Prochaine échéance connue : les notes de version de la 32.0 annoncent que trois failles de gravité moyenne ou haute, corrigées dans la 30.0, seront détaillées deux semaines après la sortie de la 32.0. Les nœuds encore en 29.x ou avant y seront exposés publiquement.

44 % des nœuds sur une version abandonnée

Le chiffre vient d'un relevé du 18 octobre du moniteur réseau de l'Institut de technologie de Karlsruhe (KIT), analysé par CryptoSlate. Sur 8 422 nœuds se déclarant Bitcoin Core et joignables en IPv4 ou IPv6, 3 671 tournaient sur la 28.x ou une version plus ancienne. Les autres se répartissaient ainsi : 3 243 sur la 31.x, 712 sur la 30.x et 635 sur la 29.x. Une fois la 32.0 publiée, ces 635 nœuds basculeront à leur tour hors maintenance : on passerait à 4 306 nœuds non maintenus, soit 51,1 %.

Deux nuances. Les versions sont déclarées par les nœuds eux-mêmes, et le relevé ignore ceux qui passent uniquement par Tor ou n'acceptent pas de connexions entrantes. Les nœuds Bitcoin Knots, le logiciel concurrent, sont comptés à part. Surtout, un nœud ancien continue de valider correctement les blocs : il n'est pas « piraté » pour autant. Il est simplement exposé aux plantages et aux attaques par saturation que les versions récentes ont corrigés, sans plus aucun correctif à venir.

Vous faites tourner un nœud : que faire maintenant

1. Vérifiez votre version. Dans l'interface graphique, menu Aide puis « À propos de Bitcoin Core ». En ligne de commande, bitcoin-cli --version, ou le champ subversion de bitcoin-cli getnetworkinfo (par exemple « /Satoshi:31.1.0/ »).

2. Si vous êtes en 28.x ou avant, n'attendez pas la 32.0. La 31.1 et la 30.3 sont disponibles dès aujourd'hui sur bitcoincore.org et restent maintenues. Passer d'une version en fin de vie à une version récente fonctionne, mais la migration du dossier de données peut prendre du temps.

3. Téléchargez uniquement depuis bitcoincore.org et vérifiez le fichier avec les empreintes SHA256SUMS et leurs signatures. Méfiez-vous des liens « Bitcoin Core 32 » qui circuleront sur les réseaux sociaux dans les jours qui viennent : c'est une occasion rêvée pour diffuser un faux installateur (nos réflexes contre ce genre de piège sont dans le guide éviter les arnaques crypto). Pour installer, arrêtez le nœud, attendez la fermeture complète, puis lancez l'installateur sous Windows ou remplacez l'application sous macOS. Configuration minimale : Windows 10 (version 1903), macOS 14 ou un noyau Linux 3.17.

4. Relisez votre fichier bitcoin.conf. Si vous avez fixé maxconnections vous-même, la valeur est conservée, mais la limite de 50 % pour les pairs de transactions s'applique quand même (-maxconnections=125 -inboundrelaypercent=100 pour retrouver l'ancien comportement). Les mineurs en solo qui produisent leurs modèles de blocs via leur nœud doivent vérifier que blockmaxweight n'est pas inférieur à blockreservedweight : cette combinaison est maintenant refusée au lieu d'être corrigée en silence. Les options -walletrbf et -debug=libevent sont dépréciées.

5. Abonnez-vous à la liste d'annonces de bitcoincore.org pour être prévenu des versions correctives, qui risquent d'être plus fréquentes avec la nouvelle politique.

Si votre nœud tourne sur une distribution prête à l'emploi (Umbrel, Start9 et consorts), la nouvelle version vous sera proposée par le magasin d'applications de la distribution, une fois que ses mainteneurs l'auront intégrée. Vérifiez alors la version affichée plutôt que de supposer qu'elle est à jour. Côté mineurs, la mise à jour ne change rien au calcul de rentabilité, qui dépend surtout de la difficulté (voir notre point sur la hausse de la difficulté d'octobre).

Cet article décrit une mise à jour logicielle : ce n'est pas un conseil en investissement.

Questions fréquentes