Le bulletin de cette semaine décrit une vulnérabilité corrigée affectant les anciennes versions de Bitcoin Core. Sont également incluses nos sections régulières résumant les récentes discussions sur la modification des règles de consensus de Bitcoin, annonçant des mises à jour et des versions candidates, et décrivant les changements notables dans les projets d’infrastructure Bitcoin populaires.

Nouvelles

• ● Divulgation de vulnérabilité affectant les anciennes versions de Bitcoin Core : Antoine Poinsot a publié sur la liste de diffusion Bitcoin-Dev pour annoncer une vulnérabilité affectant les versions de Bitcoin Core antérieures à 29.0. La vulnérabilité a été initialement divulguée de manière responsable par Eugene Siegel avec une autre vulnérabilité étroitement liée décrite dans le Bulletin #314. Un attaquant pourrait envoyer un nombre excessif d’avertissement d’adresse de nœud pour forcer un identifiant 32 bits à déborder, entraînant un crash du nœud. Cela a été partiellement atténué en limitant le nombre de mises à jour à une par pair toutes les dix secondes, ce qui, pour la limite par défaut d’environ 125 pairs, empêcherait le débordement à moins que le nœud ne soit continuellement attaqué pendant plus de 10 ans. La vulnérabilité a été complètement corrigée en utilisant des identifiants 64 bits, à partir de la version de Bitcoin Core 29.0 sortie le mois dernier.

Changement de consensus

Une section mensuelle résumant les propositions et discussions sur le changement des règles de consensus de Bitcoin.

• ● Proposition de BIP pour l’arithmétique 64 bits dans Script : Chris Stewart a publié un projet de BIP sur la liste de diffusion Bitcoin-Dev qui propose de mettre à niveau les opcodes existants de Bitcoin pour opérer sur des valeurs numériques 64 bits. Cela fait suite à ses recherches précédentes (voir les Bulletins #285, #290, et #306). Dans un changement par rapport à certaines des discussions précédentes, la nouvelle proposition utilise des nombres dans le même format de données compactSize actuellement utilisé dans Bitcoin. Des discussions connexes supplémentaires ont eu lieu dans deux fils sur Delving Bitcoin.

• ● Opcodes proposés pour permettre les covenants récursifs via des quines : Bram Cohen a posté sur Delving Bitcoin pour suggérer un ensemble d’opcodes simples qui permettraient la création de covenants récursifs via des scripts s’autoreproduisant (quines). Cohen décrit comment les opcodes pourraient être utilisés pour créer un coffre-fort simple et mentionne un système plus avancé sur lequel il travaille.

• ● Description des avantages pour BitVM de OP_CTV et OP_CSFS : Robin Linus a posté sur Delving Bitcoin à propos de plusieurs des améliorations à BitVM qui deviendraient possibles si les OP_CTV et OP_CSFS étaient ajoutés à Bitcoin lors d’un soft fork. Les avantages qu’il décrit incluent l’augmentation du nombre d’opérateurs sans inconvénients, “réduisant la taille des transactions d’environ 10x” (ce qui réduit les coûts dans le pire des cas), et permettant des peg-ins non interactifs pour certains contrats.

Mises à jour et versions candidates

Nouvelles sorties et candidats à la sortie pour des projets d’infrastructure Bitcoin populaires. Veuillez envisager de passer aux nouvelles sorties ou d’aider à tester les candidats à la sortie.

• ● LND 0.19.0-beta.rc4 est un candidat à la sortie pour ce nœud LN populaire. L’une des principales améliorations qui pourrait probablement nécessiter des tests est le nouveau bumping de frais basé sur RBF pour les fermetures coopératives.

Changements notables dans le code et la documentation

Changements récents notables dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, et BINANAs.

• ● Bitcoin Core #32155 met à jour le mineur interne pour un blocage temporel des transactions coinbase en réglant le champ nLockTime à la hauteur du bloc actuel moins un et en exigeant que le champ nSequence ne soit pas final (pour faire respecter le timelock). Bien que le mineur intégré ne soit généralement pas utilisé sur le mainnet, sa mise à jour encourage les pools de minage à adopter ces changements tôt dans leur propre logiciel en préparation pour le soft fork de nettoyage du consensus proposé dans BIP54. Le timelock des transactions coinbase résout la vulnérabilité des transactions dupliquées et permettrait de lever les vérifications coûteuses de BIP30.

• ● Bitcoin Core #28710 supprime le reste du code, de la documentation et des tests du portefeuille legacy. Cela inclut les RPCs uniquement legacy, tels que importmulti, sethdseed, addmultisigaddress, importaddress, importpubkey, dumpwallet, importwallet, et newkeypool. Comme dernière étape pour la suppression du portefeuille legacy, la dépendance à BerkeleyDB et les fonctions associées sont également supprimées. Cependant, le strict minimum du code legacy et un parser BDB indépendant (voir le Bulletin #305) sont conservés afin de réaliser la migration du portefeuille vers les portefeuilles avec descripteurs.

• ● Core Lightning #8272 désactive la recherche de pairs de secours par DNS seed du daemon de connexion connectd pour résoudre les problèmes de blocage d’appel causés par des DNS seeds hors ligne.

• ● LND #8330 ajoute une petite constante (1/c) au modèle de probabilité bimodal de recherche de chemin pour aborder l’instabilité numérique. Dans les cas limites où le calcul échouerait autrement en raison d’erreurs d’arrondi et produirait une probabilité nulle, cette régularisation fournit une solution de repli en faisant revenir le modèle à une distribution uniforme. Cela résout les bugs de normalisation qui se produisent dans des scénarios impliquant de très grands canaux ou des canaux qui ne correspondent pas à une distribution bimodale. De plus, le modèle évite désormais les calculs de probabilité inutiles et corrige automatiquement les observations de liquidité de canal obsolètes et les informations historiques contradictoires.

• ● Rust Bitcoin #4458 remplace la structure MtpAndHeight par une paire explicite du BlockMtp nouvellement ajouté et du BlockHeight déjà existant, permettant une meilleure modélisation de la hauteur de bloc et des valeurs de Median Time Past (MTP) dans les timelocks relatifs. Contrairement à locktime::absolute::MedianTimePast, qui est limité à des valeurs supérieures à 500 millions (approximativement après 1985), BlockMtp peut représenter n’importe quel timestamp 32 bits. Cela le rend adapté pour des cas limites théoriques, tels que des chaînes avec des timestamps inhabituels. Cette mise à jour introduit également BlockMtpInterval, et renomme BlockInterval en BlockHeightInterval.

• ● BIPs #1848 met à jour le statut de BIP345 en Withdrawn, car l’auteur croit que son opcode OP_VAULT proposé a été supplanté par OP_CHECKCONTRACTVERIFY (OP_CCV), un design de vault plus général et un nouveau type de covenant.

• ● BIPs #1841 fusionne BIP172, qui propose de définir formellement l’unité de base indivisible de Bitcoin comme un “satoshi”, reflétant l’usage répandu actuel et aidant à standardiser la terminologie à travers les applications et la documentation.

• ● BIPs #1821 fusionne BIP177, qui propose de redéfinir “bitcoin” pour représenter l’unité indivisible la plus petite (communément appelée 1 satoshi), plutôt que 100 000 000 unités. La proposition argue que l’alignement de la terminologie avec l’unité de base réelle réduirait la confusion causée par les conventions décimales arbitraires.