Des transactions non standard spécialement conçues pouvaient occuper un nœud Bitcoin Core quelques secondes chacune sans que l’expéditeur soit déconnecté, de quoi retarder la propagation des blocs. Signalée par Antoine Poinsot et de faible gravité, CVE-2025-46598 a été atténuée dans v30.0 grâce à une réduction du temps de validation dans le pire des cas.
Un bloc de plus de 1 Go pouvait déborder un contrôle de taille sur les nœuds Bitcoin Core 32 bits et les faire planter à l’écriture sur le disque, mais seulement sous forme de compact block et contre une victime configurée avec un -maxmempool supérieur à 3 Go contenant 1 Go de transactions. Découverte par Pieter Wuille, CVE-2025-46597 est de faible gravité ; le plafonnement de -maxmempool sur les systèmes 32 bits l’a refermée dans 29.1 et 30.0.
Les taux de frais minimaux par défaut baissent dans Bitcoin Core 28.3 : -blockmintxfee passe à 1 satoshi par kvB, -minrelaytxfee et -incrementalrelayfee à 100 satoshis par kvB. Ceux des portefeuilles ne bougent pas, et les transactions moins chères risquent de mal se propager tant que les nouvelles valeurs ne se seront pas répandues sur le réseau. Les permissions de whitelist ne s’appliquent plus non plus aux connexions entrantes onion (#33395).
FillBlock reçoit deux correctifs P2P dans Bitcoin Core 29.2 : un contrôle de mutation du witness (#32646) et une vérification d’en-tête vide avant l’appel (#33296). Les contrôles TRUC ne sont plus appliqués lors d’une réorganisation (#33504), et getblock comme getblockheader cessent de renvoyer la cible de la tête de chaîne (#33446).
Les limites d’OP_RETURN disparaissent de fait dans Bitcoin Core 30.0 : -datacarriersize vaut 100 000 par défaut et une même transaction peut porter plusieurs sorties de données, mais -datacarriersize=83 rétablit l’ancien plafond. Les taux de frais de relais par défaut tombent à 0,1 satoshi par vB, les opérations de signature legacy sont plafonnées à 2500 par transaction standard, et une nouvelle commande bitcoin chapeaute les exécutables existants.
Dans Bitcoin Core 29.1, la journalisation inconditionnelle sur disque est limitée à 1 Mio par heure pour chaque emplacement source (#32604), et une transaction standard ne peut contenir plus de 2500 opérations de signature legacy potentiellement exécutées. Les taux de frais de relais par défaut descendent à 100 satoshis par kvB, tandis que les builds 32 bits plafonnent -maxmempool à 500 Mo et -dbcache à 1 Gio.
Un peu plus de la moitié des changements de Bitcoin Core 28.2 concernent la compilation. Guix notarise désormais le bundle de l’application macOS et signe tous les binaires macOS et Windows (#31407), et depends reçoit des correctifs de compilation pour libevent sur NetBSD (#31500) et pour freetype sous cmake (#32693).
Trente et un contributeurs de Bitcoin Core ont signé une lettre : un logiciel de nœud ne devrait pas refuser de relayer des transactions portées par une demande économique durable et qui atteignent régulièrement les blocs, puisque utilisateurs et mineurs peuvent contourner ces filtres. Ils précisent que cela ne revient pas à cautionner les usages non financiers et que seuls les utilisateurs choisissent le logiciel et les règles qu’ils font tourner.
Des années de spam addr ininterrompu pouvaient faire déborder l’identifiant 32 bits du gestionnaire d’adresses de Bitcoin Core et planter le nœud : c’est ce qui restait d’une attaque déjà freinée par la limitation de débit de v22.0. La version 29.0 passe à un identifiant 64 bits et referme CVE-2024-52919, de faible gravité. Eugene Siegel l’a découverte ; Martin Zumsande a fait la modification.
Exit UPnP dans Bitcoin Core 29.0 ; -natpmp s’appuie désormais sur une implémentation intégrée de PCP et NAT-PMP au lieu de libnatpmp. L’ephemeral dust arrive comme nouvelle règle, un correctif de la double réservation de poids de bloc ajoute -blockreservedweight, et les nœuds réclament les parents manquants à tous les pairs ayant annoncé une orpheline. Les versions 26.x et antérieures atteignent la fin de maintenance.
Avec -port, Bitcoin Core 28.1 calcule le port d’écoute onion par défaut en ajoutant un à ce port, au lieu de le figer à 8334 sur le mainnet : plusieurs nœuds locaux peuvent de nouveau cohabiter sans collision au démarrage. Les lignes HiddenServicePort manuelles de torrc devront peut-être être modifiées. Les données secrètes sont aussi effacées dans DecodeExtKey (#31166).
Un pair qui annonce un bloc puis se met à traîner pouvait laisser un nœud Bitcoin Core patienter jusqu’à 10 minutes avant d’aller voir ailleurs, et les attaquants pouvaient recommencer. De gravité moyenne, signalée et corrigée par Greg Sanders, CVE-2024-52922 est atténuée dans v25.1 et v26.0, capables de demander aussitôt un bloc à 3 pairs compact block à haut débit au maximum.
La version 27.2 de Bitcoin Core referme une situation de concurrence dans la détection des auto-connexions (#30394) et corrige les appels FillPSBT qui renvoyaient à tort complete=true (#30357). Le thread de chargement des blocs et l’ordonnanceur s’arrêtent désormais dans un autre ordre (#30435), et le code compile avec miniupnpc 2.2.8 et GCC 15.
Dans Bitcoin Core avant v25.0, des blocs mutés envoyés par un seul pair pouvaient effacer l’état de téléchargement des autres pairs annonçant le même bloc, si bien que le nœud oubliait un compact block en cours de reconstruction. Suhas Daftuar a remarqué le problème, et #27608 cantonne chaque pair à son propre état. CVE-2024-52921 est de gravité moyenne.
Les nœuds sous Bitcoin Core antérieur à v25.0 pouvaient être plantés à distance par un second message blocktxn pour un même bloc, qui déclenchait une assertion exigeant que FillBlock ne tourne qu’une fois. Inutile de provoquer une collision de short-id : inclure des transactions absentes de la racine de Merkle du bloc menait au même chemin. Niklas Gögge a découvert et corrigé ce bug de gravité élevée, CVE-2024-35202.
Début mai 2023, un pic d’activité sur le réseau, aggravé par des nœuds espions, a ralenti la propagation des blocs et des transactions : trier des ensembles inv-to-send devenus trop gros accaparait presque tout le temps du thread P2P. De gravité moyenne, le problème a été corrigé dans Bitcoin Core v25.0 par #27610, qui écarte plus tôt les transactions sorties du mempool et vide ces ensembles plus vite à mesure qu’ils grossissent.
Testnet4 (BIP94) fait son entrée dans Bitcoin Core 28.0, avec un relais de paquets limité aux paires 1 parent-1 enfant, des transactions TRUC standard selon BIP 431 et un nouveau type de sortie Pay To Anchor. -mempoolfullrbf vaut désormais 1 par défaut, et libbitcoinconsensus disparaît après sa dépréciation dans 27.0.
Des chaînes d’en-têtes à faible difficulté pouvaient planter à distance les nœuds Bitcoin Core antérieurs à v24.0.1, et une seule chaîne forgée pouvait resservir contre n’importe quel nœud du réseau. Le correctif #25717 oblige un nœud à vérifier qu’une chaîne porte assez de travail avant de la stocker, ce qui a aussi mis fin à la dépendance aux checkpoints face aux attaques connues. Gravité : élevée.
Le spam de messages addr pouvait faire tomber un nœud Bitcoin Core : 2^32 insertions dans addrman faisaient déborder un compteur d’identifiants sur 32 bits et déclenchaient une assertion. Eugene Siegel a signalé ce bug de gravité élevée en 2021, et v22.0 intègre le correctif de Pieter Wuille.
En se faisant passer pour un appareil UPnP sur le réseau local, un attaquant pouvait bombarder un nœud Bitcoin Core de réponses M-SEARCH surdimensionnées jusqu’à épuiser sa mémoire. Seuls les nœuds lancés avec -miniupnp étaient exposés, la bibliothèque étant sinon désactivée par défaut. Ce bug de faible gravité a été corrigé dans v22.0.