À la signature, Bitcoin Core 26.2 ne présume plus qu’un TapMiniscript est sain (#29853), getnetworkhashps renvoie une erreur en cas de paramètres invalides (#28554) et setmocktime a désormais un maximum imposé (#29869). La compilation fonctionne aussi avec miniupnpc 2.2.8.
Avant Bitcoin Core 0.10.1, les messages reçus pouvaient atteindre 32 Mio : un attaquant pouvait forcer l’allocation d’autant de RAM par connexion et peut-être planter le nœud. Après le signalement d’Evil-Knievel, utilisateur de Bitcointalk, #5843 a ramené la limite à 2 Mio, remontée plus tard à 4 Mo pour Segwit. Annoncée pour 2015, la divulgation a été reportée et les détails ne sont sortis qu’en 2024.
L’IPv6 permettait de gonfler à peu de frais la liste de bannissement illimitée de Bitcoin Core, et chaque message GETADDR imposait ensuite de la parcourir pour chaque adresse renvoyée, jusqu’à 2500. Jugés de gravité élevée, le plantage mémoire et la surcharge CPU ont tous deux été corrigés par #19219, livré dans 0.20.1 et 0.21.0.
Deux bugs dans le traitement du message version, un dépassement d’entier signé et une erreur de logique dans abs64, permettaient à un attaquant de décaler le temps ajusté d’une victime jusqu’à lui faire rejeter les nouveaux blocs, jugés trop datés dans le futur. Encore fallait-il figurer parmi les 200 premiers pairs à se connecter. De gravité moyenne, la faille a été corrigée dans Bitcoin Core 0.21.0.
Ouvrir un lien de paiement BIP72 piégé pouvait planter Bitcoin-Qt : son paramètre r pouvait pointer vers un énorme fichier, pour lequel l’application tentait d’allouer la mémoire pendant que le téléchargement tournait en silence en arrière-plan. Ce bug de gravité moyenne a disparu quand #17165 a retiré la prise en charge de BIP70, livré dans 0.20.0.
Des transactions orphelines spécialement conçues, invalides mais coûteuses à valider, pouvaient bloquer un nœud pendant des heures : chaque transaction nouvellement acceptée déclenchait une recherche quadratique dans le cache d’orphelines. Le #15644 de Pieter Wuille interrompt ce travail pour traiter les nouveaux messages dès qu’une correspondance apparaît. Ce correctif d’un bug de gravité élevée a été livré avec Bitcoin Core 0.18.0.
Un message GETDATA malformé pouvait laisser le thread net_processing tourner à 100 % du CPU dans les versions de Bitcoin Core antérieures à 0.20.0, avec 1,5 Mo de mémoire en plus par pair attaquant. Les autres pairs continuaient d’être servis, d’où la note faible. John Newbery a découvert le bug et l’a corrigé dans #18808.
Bâtis directement sur le bloc de genèse et ne demandant qu’une difficulté de 1, des en-têtes passaient à travers la logique des checkpoints de Bitcoin Core 0.12.0 jusqu’à 0.15.0 : un spammeur pouvait faire grossir mapBlockIndex sans limite et peut-être planter le nœud faute de mémoire. Cory Fields a signalé ce bug de gravité moyenne en 2017, et #11028 l’a refermé.
Un seul INV rempli de 50 000 éléments de type bloc pouvait pousser un nœud à mettre en file 50 000 réponses getheaders d’environ 1 ko chacune, et un pair refusant de les lire maintenait plein ce tampon d’envoi de 50 Mo. Le #18962 de John Newbery, présenté comme une économie de bande passante, a limité l’envoi à un GETHEADERS par INV et a été livré dans 0.20.0.
En retenant ses réponses GETDATA, puis en noyant la table g_already_asked_for de 50 000 entrées sous de fausses annonces pour en évincer une transaction, un attaquant pouvait la réannoncer sans fin et empêcher la victime de la demander à quiconque d’autre. John Newbery a rendu public ce bug de gravité moyenne ; le #19988 de Pieter Wuille l’a corrigé dans Bitcoin Core 0.21.0.
Un second dépassement de tampon dans miniupnpc, découvert par Wladimir J. Van Der Laan, laissait fuir des données et pouvait s’enchaîner avec CVE-2015-6031 pour aboutir à une exécution de code à distance, qu’il a démontrée contre le miniupnpc 1.6-precise d’Ubuntu. Son exploit ne se transposait pas directement à Bitcoin Core, et la version 0.12 a apporté le correctif en février 2016.
Que des corrections de bugs dans Bitcoin Core 27.1 : l’augmentation de frais de l’interface graphique pour les transactions non signées est réparée, son champ d’IP de proxy n’accepte plus de port, et GetAddedNodeInfo() détecte désormais les pairs CJDNS ajoutés par addnode (#30085). La gestion de TapMiniscript à la signature change aussi (#29853).
Le transport BIP324 v2 s’active par défaut dans Bitcoin Core 27.0, et le nouvel algorithme CoinGrinder cherche le jeu d’entrées le plus léger à partir de 30 sat/vB. Le temps ajusté par le réseau quitte le code de consensus au profit de l’heure système : une horloge exacte compte donc davantage pour les opérateurs. libbitcoinconsensus est déprécié, avec un retrait prévu pour v28.
Les nœuds sous Bitcoin Core 25.2 cessent de traiter les blocs mutés (#29412). La mise à jour corrige aussi un segfault de getrawtransaction (#29003), un use-after-free dans WalletBatch::EraseRecords (#29176) et un plantage de l’interface graphique à la sélection de « Mask values ».
Les sessions I2P de Bitcoin Core 26.1 utilisent à la fois le chiffrement ECIES-X25519 et ElGamal (#29200), et le nœud journalise désormais sa progression pendant le chargement du mempool. Côté correctifs : refus de traiter les blocs mutés (#29412) et portefeuille qui saute la sélection de pièces BnB quand SFFO est actif (#28994).
Le transport BIP324 v2 fait ses débuts à titre expérimental dans Bitcoin Core 26.0, désactivé par défaut et à activer avec -v2transport. Une nouvelle commande RPC, loadtxoutset, charge des instantanés assumeutxo et donne un nœud utilisable en quelques minutes, pendant que le chainstate d’origine termine sa validation en arrière-plan ; submitpackage envoie quant à elle des transactions brutes au mempool sous forme de paquet.
Bitcoin Core 24.2 ne sert plus d’estimations de frais périmées (#27622) et corrige le traitement RPC des adresses bech32 invalides (#27727). La plupart des autres changements touchent le système de build et la CI, dont un correctif pour la compilation du paquet Qt macOS avec l’éditeur de liens de Xcode 15 (#28543).
Le téléchargement parallèle des compact blocks arrive dans Bitcoin Core 25.1 (#27626). D’autres correctifs visent un plantage REST sur /deploymentinfo (#27853), l’arrêt du serveur après la déconnexion d’un client distant (#28551) et la migration de portefeuille, qui refuse désormais les scripts invalides (#28125).
Les rescans des portefeuilles à descripteurs s’accélèrent dans Bitcoin Core 25.0 lorsque les filtres compacts de blocs BIP158 sont disponibles via -blockfilterindex=1, et une nouvelle commande RPC, scanblocks, interroge ces filtres. Les règles de relais acceptent désormais les transactions à partir de 65 octets hors witness. En -blocksonly, la mémoire maximale du mempool passe de 300 Mo à 5 Mo.
Trois changements P2P portent Bitcoin Core 23.2 : plus de corruption de peers.dat (#26909), plus d’effacement prématuré de l’état de téléchargement des autres pairs (#27608) et des files inv-to-send plus rapides (#27610). Le reste concerne le build et la CI, comme la compilation de bdb avec clang-16 sur aarch64.