Environ quatre nœuds Bitcoin Core joignables sur dix, observés lors d’un balayage du réseau le 18 octobre, tournent sur des branches que le projet ne corrige plus. Les correctifs de sécurité accélérés adoptés par Bitcoin Core le 22 octobre ne les atteindront donc pas. CryptoSlate, dans un article publié le 24 octobre, a compté 3 671 pairs Core sur 8 422 (43,6 %) en fin de vie, à partir d’un instantané de l’Institut de technologie de Karlsruhe (KIT). Coindaro a recompté le même fichier du KIT et trouve une part voisine, environ 44 %.
Ce chiffre est une estimation tirée d’un seul balayage, avec des numéros de version que les nœuds déclarent eux-mêmes. blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il n’a rien d’inédit : une part d’environ 43 % circulait déjà en mai. Ce qui change, c’est la politique qui l’entoure. Bitcoin Core publiera désormais certains correctifs en quelques jours, mais seulement pour les trois branches qu’il maintient. Un noeud bitcoin resté sur une branche plus ancienne reste en dehors de ce circuit.
Comment le nombre de noeuds Bitcoin a été établi
Le KIT exploite depuis longtemps un moniteur du réseau Bitcoin et publie les instantanés bruts des pairs qu’il atteint. Il ne publie pas de pourcentage de nœuds obsolètes. Les 43,6 % sont un calcul propre à CryptoSlate, réalisé à partir du fichier d’instantané du 18 octobre, qui recense 9 691 pairs joignables en IPv4 et IPv6. CryptoSlate a retenu les 8 422 qui se déclarent Bitcoin Core et écarté le reste, dont les nœuds sous Bitcoin Knots.
L’échantillon a des angles morts, que l’article signale lui-même. Les nœuds joignables uniquement via Tor, ceux qui n’acceptent pas de connexions entrantes et l’infrastructure privée des plateformes, des conservateurs et des mineurs n’y figurent pas. Quelles que soient les versions qu’ils font tourner, aucun balayage extérieur ne peut les voir.
La ventilation de CryptoSlate laisse aussi un petit écart. Ses quatre groupes (31.x, 30.x, 29.x, puis 28.x et antérieures) totalisent 8 261 pairs, et non 8 422. L’article n’explique pas les 161 pairs manquants.
Coindaro a téléchargé le fichier du KIT et trié les 9 691 entrées selon l’agent utilisateur. En ne comptant que les chaînes Bitcoin Core ordinaires (de la forme /Satoshi:31.1.0/, sans mention supplémentaire), on obtient 8 418 agents Core, très près des 8 422 de CryptoSlate. 1 096 autres agents mentionnent Knots (11 % de l’ensemble des pairs) et 177 relèvent d’autres clients ou de versions modifiées. Parmi les 8 418 agents Core, 3 742 étaient en version 28 ou antérieure, dont 242 dans l’antique série 0.x. Cela fait 44,5 %. Les petites différences avec le décompte de CryptoSlate tiennent à des choix de classement, par exemple le traitement de Knots, des versions candidates et des versions modifiées.
| Branche | Statut au 25 octobre 2026 | Décompte CryptoSlate (KIT, 18 oct.) | Recompte Coindaro (même fichier) |
|---|---|---|---|
| Versions candidates 32.0 | Pas encore publiée | non indiqué | 37 |
| 31.x | Maintenue jusqu’à la 34.0 | 3 243 | 3 278 |
| 30.x | Maintenue jusqu’à la 33.0 | 712 | 721 |
| 29.x | Maintenue jusqu’à la 32.0 | 635 | 640 |
| 28.x et antérieures | Fin de vie (28.x depuis le 19 avril 2026) | 3 671 (43,6 %) | 3 742 (44,5 %) |
| Base de la part | 8 422 pairs Core | 8 418 agents Core, Knots exclus |
Deux réserves supplémentaires valent pour les deux décomptes. Le fichier ne correspond pas à un instant unique : sa connexion la plus récente date du 18 octobre, mais les plus anciennes entrées remontent au 26 janvier 2026, si bien que des pairs périmés s’y mêlent. En ne gardant que les 5 384 agents Core vus depuis le 1er octobre, Coindaro trouve encore 43,3 % sur des branches en fin de vie. Et un nœud peut afficher n’importe quelle chaîne de version : les données montrent ce que les nœuds disent faire tourner, pas ce qu’ils font tourner.
Une part comparable circulait déjà en mai
Il ne faut pas lire le chiffre du 18 octobre comme une dégradation récente. Le 6 mai 2026, lendemain de la divulgation par Bitcoin Core de la faille CVE-2024-52911, The Block rapportait qu’une estimation très citée, qu’il rattachait au tableau de bord de nœuds de Clark Moody, plaçait environ 43 % des nœuds sur une version antérieure à la 29. Elle venait d’un autre traceur, avec une autre méthode : on ne peut donc pas aligner les deux chiffres pour en tirer une tendance, ni à la hausse ni à la baisse.
D’autres traceurs donnent encore d’autres images. CryptoTicker, à partir d’un instantané de btcnodes.io du 15 septembre, a compté 26 516 nœuds et placé 60,40 % de ceux qui portent un identifiant standard sur la série 29 ou plus ancienne, un découpage qui inclut la branche 29.x, toujours maintenue. Prises seules, les versions 28.x et antérieures représentaient 27,09 % de cet échantillon. Comme le KIT, cet instantané laisse de côté les nœuds joignables uniquement via Tor. Il montrait aussi 4 459 nœuds (17,2 %) déclarant Knots, contre 11 % dans le fichier du KIT. Les traceurs qui comptent autour de 25 000 à 26 000 nœuds et les 9 691 pairs IPv4 et IPv6 du KIT ne mesurent pas le même réseau : leurs pourcentages ne doivent jamais être mélangés.
La politique de correctifs rapides ne couvre que les branches 31.x, 30.x et 29.x
La nouvelle règle, annoncée par Antoine Poinsot sur la liste de diffusion bitcoindev, crée une catégorie pour les bugs faciles à trouver, par exemple avec une simple requête à un modèle d’IA. Pour ceux-là, la longue attente de plusieurs mois avant divulgation disparaît. « Pour ces failles faciles à trouver, c’est le mauvais compromis », a écrit Poinsot dans son message du 22 octobre. Le correctif sort vite, dans une version intermédiaire pour chaque branche maintenue, accompagné d’un avis de sécurité. Le détail de la règle figure dans notre article du 23 octobre sur la nouvelle politique de sécurité de Bitcoin Core.
« Chaque branche maintenue » est l’expression clé. La page sur le cycle de vie de Bitcoin Core indique que le projet maintient toujours les trois dernières versions majeures, aujourd’hui 31.x, 30.x et 29.x, et que les versions en fin de vie ne reçoivent en général pas de correctifs de sécurité. La version 28.x est arrivée en fin de vie le 19 avril 2026 ; la 27.x, le 10 octobre 2025.
Le groupe des versions prises en charge est sur le point de rétrécir à nouveau. La version 32.0 en était encore au stade de la version candidate le 24 octobre, sans date fixée. Dès sa sortie, la 29.x perdra son support. Sur l’échantillon de CryptoSlate, cela placerait 4 306 pairs, soit 51,1 %, sur des branches non prises en charge si personne ne mettait à jour. Le recompte de Coindaro donne 4 382 sur 8 418, soit 52,1 %. Dans les deux cas, environ la moitié.
Fin de vie de Bitcoin Core ne veut pas dire compromis
Un nœud resté sur une branche non prise en charge continue de télécharger et de vérifier chaque bloc selon les mêmes règles de consensus. La nouvelle politique ne touche pas à ces règles, et CryptoSlate a insisté sur le fait que son décompte mesure l’éligibilité aux correctifs, pas une compromission. Dans les documents examinés par Coindaro, aucune exploitation des bugs divulgués contre d’anciens nœuds n’est documentée. Au 23 octobre, aucun avis de sécurité n’avait encore été émis au titre de la règle des bugs faciles à trouver.
Le risque est d’une autre nature : plantages et dénis de service provoqués par des bugs déjà publics. Le cas le plus net est CVE-2024-52911, une utilisation après libération de mémoire (use-after-free) dans la validation des blocs et des scripts, divulguée le 5 mai 2026. D’après les avis de sécurité du projet et The Block, un mineur pouvait faire planter des nœuds avec un bloc invalide spécialement construit, une attaque qui coûte de la vraie preuve de travail. Le projet l’a classée en gravité élevée (High) et a jugé l’exécution de code à distance improbable ; The Block a ajouté que les règles de consensus n’étaient pas touchées. La faille se trouve dans toutes les versions de la 0.14.0 à la 28.x. Cory Fields, du Digital Currency Initiative du MIT, l’a signalée en privé le 2 novembre 2024, et le correctif est sorti dans la 29.0 en avril 2025, soit 388 jours avant la divulgation publique selon le décompte de CryptoSlate.
Un lot divulgué le 24 octobre 2025 et corrigé dans la version 30.0 comprenait un plantage distant rare sur les systèmes 32 bits (CVE-2025-46597), une attaque par épuisement du processeur via des transactions non confirmées (CVE-2025-46598) et deux moyens de remplir le disque d’un nœud (CVE-2025-54604 et CVE-2025-54605). La page des avis ne précise pas quelles versions plus anciennes sont touchées.
Il existe une raison structurelle pour laquelle les vieilles branches portent davantage de bugs publics, et il s’agit de la lecture que fait Coindaro du texte de la politique, non d’une déclaration du projet. Pour les failles de gravité moyenne et élevée, Bitcoin Core attend deux semaines après le passage en fin de vie de la dernière branche touchée avant de publier les détails. Par construction, les bugs divulgués sont donc ceux qui ne sont plus corrigés nulle part où un ancien nœud pourrait recevoir un correctif. Notre guide sur les endroits où les piratages crypto surviennent vraiment explique pourquoi ce sont les logiciels autour de la chaîne, et non la chaîne elle-même, qui forment d’ordinaire le maillon faible.
Pourquoi les opérateurs de nœuds mettent à jour lentement
Les nœuds en retard sont un phénomène ancien. Dans une étude publiée en février 2024, le développeur Jameson Lopp a mesuré, avec les données hebdomadaires de Bitnodes, le temps nécessaire pour que 95 % du pic d’adoption d’une version soit passé à autre chose. Ce délai est monté d’environ un an avant juillet 2018 à environ deux ans. Depuis 2021, le pic d’adoption survient six à neuf mois après la sortie. L’explication de Lopp, qu’il présente comme une hypothèse, est l’essor des matériels et logiciels de nœuds prêts à brancher, en partie porté par les utilisateurs de Lightning, dont les propriétaires sont souvent moins techniques et moins enclins à mettre à jour à la main.
Beaucoup de ces machines ont été installées une fois, puis laissées telles quelles. Pour elles, une politique qui accélère les correctifs sur les branches maintenues ne change rien tant que le propriétaire, ou l’éditeur du paquet, ne fait pas avancer le nœud.
Comment vérifier la version de son noeud Bitcoin
Les opérateurs qui font tourner Bitcoin Core en ligne de commande peuvent saisir bitcoin-cli getnetworkinfo. La documentation RPC liste un champ « subversion », la chaîne de version du serveur (par exemple /Satoshi:31.0.0/), à côté d’un champ numérique « version ». Tout ce qui commence par 28 ou moins relève d’une branche en fin de vie.
- La page sur le cycle de vie recommande la dernière version de maintenance de la version majeure la plus récente que vous pouvez utiliser ; aujourd’hui, c’est la dernière version intermédiaire 31.x.
- Comme pour toute mise à jour logicielle, téléchargez depuis le site officiel, bitcoincore.org, et vérifiez les signatures des fichiers de la version avant l’installation.
- Sur un paquet de nœud comme Umbrel ou Start9, Bitcoin Core se met en général à jour via la boutique d’applications du paquet : c’est là qu’il faut regarder la version proposée.
Qui doit bouger en premier dépend du bug. Dans la discussion du changement sur GitHub, Poinsot a donné l’exemple d’une faille dans la création des modèles de blocs, pour laquelle les mineurs doivent mettre à jour au plus vite alors que les commerçants peuvent procéder avec plus de prudence. C’est l’une des raisons pour lesquelles le projet veut que les avis de sécurité contiennent des détails. Une remarque en passant pour ceux qui comptent passer à la 32.0 plus tard : selon CryptoSlate, elle fait passer le format PSBT par défaut à la version 2, et un utilisateur a constaté le 14 octobre que des fichiers issus du nouveau portefeuille graphique ne s’important pas dans d’anciens cosignataires Core, avec un correctif reporté à la 32.1.
Bitcoin Core n’est pas le seul logiciel de nœud sommé de corriger plus vite ; l’implémentation Lightning Eclair a publié à la mi-octobre un correctif qui empêche des pages web d’envoyer des commandes à des nœuds Lightning. Plus de contexte sur le réseau sur notre page Bitcoin.
Ce que l’on ignore encore
La date de sortie de Bitcoin Core 32.0 n’est pas fixée, et avec elle le jour où la 29.x sortira du support. Aucun bug n’a encore été traité dans la catégorie des failles faciles à trouver : personne n’a donc vu en pratique à quelle vitesse une version intermédiaire arrive. Les 161 pairs absents de la ventilation de CryptoSlate restent inexpliqués. Et la part de logiciels obsolètes chez les plateformes d’échange, les conservateurs et les pools de minage, qui n’apparaissent jamais dans les balayages publics, n’est pas connue du tout.
Deux points à surveiller : le premier avis de sécurité émis au titre de la règle des bugs faciles à trouver, et la répartition des versions dans les instantanés du KIT une fois la 32.0 sortie.