Les portefeuilles de Bitcoin Core 24.1 effacent la clé maîtresse au verrouillage pour qu’elle ne reste pas en mémoire (#27080), et une sérialisation unique prévient la corruption de peers.dat (#26909). Les files inv-to-send vont plus vite (#27610), et un segfault REST sur les URI invalides disparaît (#27468).
La commande deriveaddresses ne plante plus à l’index 2147483647 dans Bitcoin Core 23.1 (#26275), et un segfault sous MacOS 13 déclenché par certaines notifications disparaît. L’interface graphique refuse désormais de chiffrer les portefeuilles watch-only, et Qt5 passe en 5.15.3 (#24668).
Dans Bitcoin Core 22.1, un simple -persistmempool équivaut enfin à -persistmempool=1, alors qu’il désactivait par erreur la persistance du mempool (#23061). Le calcul des frais arrondit vers le haut pour ne pas tomber sous le taux attendu (#22949), et un segfault de portefeuille lié à external_spk_managers est corrigé (#23333).
La synchronisation des en-têtes gagne une phase de présynchronisation dans Bitcoin Core 24.0.1 : pour parer à un éventuel déni de service, les nœuds vérifient le travail cumulé d’un pair avant de stocker ses en-têtes, ce qui peut ralentir la première synchronisation (#25717). Autres nouveautés : la commande RPC sendall et une option mempoolfullrbf qui accepte les remplacements sans signalement BIP125, tandis que les portefeuilles passent par défaut au RBF opt-in.
CJDNS est pleinement pris en charge dans Bitcoin Core 23.0, et l’ancienne préférence pour les pairs sur le port 8333 disparaît (#23542). L’estimation des frais tient désormais compte des remplacements RBF, le paramètre de démarrage -rescan est supprimé, et les binaires Linux embarquent des tracepoints expérimentaux.
Les pairs qui se comportent mal apparaissent comme « discouraged » et non plus bannis dans les journaux de Bitcoin Core 0.20.2 : ils peuvent toujours se connecter mais sont évincés en premier, et cet état s’efface au redémarrage. -walletnotify se déclenche de nouveau pour les transactions du portefeuille retirées du mempool à cause d’un conflit avec un nouveau bloc, et les PSBT transportent les UTXO witness et non-witness pour les entrées segwit.
Les adresses colportées par les pairs voient leur débit limité dans Bitcoin Core 0.21.2 (#22569), et une ligne de commande contenant -noincludeconf=0 ne fait plus planter l’analyseur (#22002). Dans l’interface graphique, les messages d’erreur d’URI ne répètent plus la saisie de l’utilisateur (gui#280).
Bitcoin Core 22.0 ajoute la prise en charge d’I2P et abandonne les adresses Tor v2, que le réseau Tor lui-même a lâchées. Le mappage de ports NAT-PMP fait son apparition, les RPC exigent Bech32m pour les adresses witness natives de version 1 selon BIP 350, et les binaires officiels sortent d’une compilation basée sur Guix.
Les modèles de blocs de Bitcoin Core 0.21.1 signalent la préparation à taproot pendant environ trois mois. Si 90 % des blocs d’une période d’ajustement de 2016 blocs signalent, taproot est verrouillé et cette version applique les BIP 341 et 342 à partir du bloc 709 632. Sous Windows, une invite d’installation supplémentaire s’affiche à cause d’un problème de certificat de signature de code.
Bitcoin Core 0.21.0 ajoute les réseaux de test signet (BIP325) et embarque les règles de consensus de Taproot issues de BIP341 et BIP342, actives sur signet mais pas sur le mainnet. Les nœuds gagnent aussi les services cachés Tor v3, le relais wtxid de BIP339 et la possibilité de servir à leurs pairs les filtres compacts BIP157.
Finis les bannissements automatiques dans Bitcoin Core 0.20.1, remplacés par un filtre de découragement : les pairs fautifs peuvent encore se connecter, mais sont évincés en priorité. Les transactions de portefeuille en conflit déclenchent à nouveau -walletnotify, cassé depuis v0.19, et les PSBT des entrées segwit portent désormais les UTXO witness et non-witness.
Les messages reject de BIP61 et la prise en charge des paiements BIP70 sont tous deux retirés de Bitcoin Core 0.20.0, qui cesse aussi d’utiliser OpenSSL. Une option expérimentale, -asmap, répartit les connexions aux pairs entre systèmes autonomes, et les réglages rpcwhitelist peuvent restreindre un utilisateur RPC à certains appels.
Les utilisateurs de Tor peuvent désormais accéder au site de Bitcoin Core par une adresse onion, une demande fréquente. Ce service caché offre une voie de plus pour contourner la censure et un chemin de confiance qui ne dépend ni des autorités de certification ni du DNS.
Passer deux fois -blockfilterindex=basic ne provoque plus d’erreur fatale leveldb dans Bitcoin Core 0.19.1, une mise à jour de maintenance. La valeur origfee renvoyée par bumpfee est aussi corrigée, et des contrôles de bornes s’ajoutent sur les index et les montants des PSBT.
Qui télécharge 0.19.0 récupère en réalité 0.19.0.1, un problème étant apparu juste après la phase de rc. Au programme de cette version de Bitcoin Core : un indicateur de portefeuille avoid_reuse capable d’écarter d’une opération les adresses déjà utilisées, une commande RPC getbalances appelée à remplacer les anciens appels de solde, et les filtres de blocs BIP158 via -blockfilterindex.
Un proxy SOCKS malveillant pouvait écraser la pile d’un nœud Bitcoin Core, révèle la divulgation complète de CVE-2017-18350. Ce dépassement de tampon, introduit avec la prise en charge de SOCKS5 dans v0.7.0rc1, a été discrètement corrigé dans 0.15.1 ; seuls étaient exposés les nœuds configurés pour utiliser un tel proxy, sur des systèmes où le type char est signé.
La version 0.18.1 de Bitcoin Core corrige la hauteur d’élagage renvoyée par pruneblockchain, et signrawtransactionwithkey signale désormais une erreur quand il manque un redeemScript ou un witnessScript. Côté interface graphique, un bug d’ouverture du fichier de configuration sur Mac disparaît.
Les mineurs qui appellent getblocktemplate sans la règle segwit reçoivent désormais une erreur dans Bitcoin Core 0.18.0, car cette omission réduit leurs récompenses. La configuration RPC se durcit aussi : rpcallowip ne fait plus écouter le nœud sur toutes les interfaces, et un caractère dièse dans rpcpassword bloque le démarrage.
Bitcoin Core 0.17.1 rend ses labels à listtransactions : le paramètre account, déprécié et rebaptisé dummy dans 0.17.0, devient label. Les correctifs concernent un cas limite de dépassement à la désérialisation et un bug de signature PSBT.
Les portefeuilles peuvent désormais être chargés, créés et déchargés à chaud en RPC dans Bitcoin Core 0.17.0, et plus seulement au démarrage. Un nouvel indicateur, -avoidpartialspends, dépense ensemble les pièces reçues à la même adresse, au risque de frais plus élevés, et une API de labels remplace l’API account, dépréciée. CVE-2018-17144 ne touche pas cette version.