Bitcoin Core v32.0rc1 : des changements de protocole côté portefeuille pourraient perturber des applications

Bitcoin Core v32.0rc1 ouvre une phase de tests de compatibilité intensive entre le 14 septembre et le 10 octobre pour les opérateurs de nœuds, les fournisseurs de wallets et les services qui s'appuient sur les interfaces RPC de Bitcoin Core. Le candidat a été étiqueté avec une signature vérifiée le 14 septembre. Le calendrier officiel vise le tag final v32.0 au 10 octobre, soit un intervalle de 26 jours. Une prévisualisation publiée en août par CryptoSlate indiquait un objectif RC1 au 10 septembre, alors que le planning à jour affiche le 14 septembre, ce qui crée un écart de quatre jours sans démontrer qu'une échéance inchangée aurait été manquée. Le tag v32.0rc1 correspond à un pré-livraison, pas à une mise à niveau finale de production. Il n'annonce pas non plus l'activation de nouvelles règles de consensus. Une évolution associée au projet BIP 323 modifie la manière dont Bitcoin Core traite les bits de signalement et les avertissements liés à des déploiements inconnus, mais la proposition reste au statut "Draft". Pour démarrer, les opérateurs peuvent suivre la logique recommandée dans le guide de test des RC : exercer les fonctionnalités utilisées au quotidien dans des répertoires de données temporaires distincts, puis comparer le candidat à la version précédente. La page de téléchargement officielle indique 31.1 comme base actuelle. Cette approche permet d'identifier des écarts au démarrage du nœud, dans le comportement du wallet et dans les réponses RPC, sans traiter le RC comme une mise à jour de routine. Côté performance, le principal changement mentionné dans les notes (draft) de v32 concerne le préchargement parallèle des sorties de transaction pendant la connexion des blocs. Le réglage utilise par défaut huit workers, monte jusqu'à 16 et peut être désactivé. Des validations limitées par le disque, testées avec plusieurs paramètres, aideront à déterminer si l'accélération du traitement des blocs s'accompagne de coûts jugés trop élevés en CPU, mémoire ou latence de stockage sur le matériel de l'opérateur. Les intégrations wallets et services font face à un risque distinct de rupture. Quatre RPC basculeront par défaut vers PSBTv2, tandis que d'autres interfaces suppriment des champs obsolètes ou rejettent des arguments acceptés par des versions plus anciennes. Les équipes qui créent, convertissent ou effectuent des "feebump" de PSBT doivent suivre ces transactions jusqu'aux parseurs et signers en aval. La gestion des frais exige aussi des scénarios de défaillance. Le chemin par défaut d'estimatesmartfee combine les estimateurs "blockpolicy" et "mempool", peut produire une estimation plus basse et peut renvoyer une erreur si l'un des composants échoue. Les opérateurs sont invités à observer le démarrage ainsi que les situations de mempool clairsemé ou dégradé, puis à vérifier que la supervision et les bascules explicites vers blockpolicy fonctionnent comme prévu. La réécriture du serveur HTTP étend la surface de test au-delà du nœud. Elle introduit une limite d'en-tête à 8!162 octets, un traitement plus strict des en-têtes malformés, un plafond par défaut de 16 connexions RPC, de nouveaux contrôles de cache REST et une déconnexion immédiate des adresses clientes non autorisées. Ces points peuvent se manifester dans les reverse proxies, les checks de santé, les pools de clients et les gestionnaires d'erreurs. Le scénario de retour arrière mérite la même attention. Un index des transactions reconstruit utilise moins de la moitié de l'espace disque, mais les versions plus anciennes ne peuvent pas lire le nouveau format : une rétrogradation peut donc déclencher une nouvelle reconstruction durant des heures. Les opérateurs axés sur la confidentialité gagneront aussi à reproduire les chemins d'échec de diffusion privée autour du correctif de repli Tor, de la file d'attente de 10!000 entrées, de la limite de 1!000 tentatives et du comportement de relais sous charge. Le tag final restant une cible, ces cas limites constituent le travail concret de la fenêtre RC. Le post "Major Bitcoin Core update changes default wallet protocols, risking temporary disruption across popular apps" a été publié en premier sur CryptoSlate.