Le bulletin de cette semaine partage une mise à jour sur le fuzzing différentiel des implémentations de Bitcoin et LN et propose des liens vers un nouveau papier sur les verrous chiffrés pour les contrats de calcul responsables. Sont également incluses nos sections régulières résumant les récentes questions et réponses de Bitcoin Stack Exchange, annoncant de nouvelles versions et des candidats à la publication, ainsi que les résumés des modifications notables apportées aux logiciels d’infrastructure Bitcoin populaires.

Nouvelles

• ● Mise à jour sur le fuzzing différentiel des implémentations de Bitcoin et LN : Bruno Garcia a publié sur Delving Bitcoin pour décrire les progrès récents et les accomplissements de bitcoinfuzz, une bibliothèque et des données associées pour le fuzz testing de logiciels et bibliothèques basés sur Bitcoin. Les accomplissements incluent la découverte de “plus de 35 bugs dans des projets tels que btcd, rust-bitcoin, rust-miniscript, Embit, Bitcoin Core, Core Lightning, [et] LND.” La découverte de divergences entre les implémentations LN n’a pas seulement révélé des bugs mais a également conduit à des clarifications de la spécification LN. Les développeurs de projets Bitcoin sont encouragés à envisager de rendre leur logiciel une cible prise en charge par bitcoinfuzz.

• ● Verrous chiffrés pour les contrats de calcul responsables : Liam Eagen a posté sur la liste de diffusion Bitcoin-Dev à propos d’un papier qu’il a écrit sur un nouveau mécanisme pour créer des contrats de calcul responsables mais basé sur les circuits chiffrés. Cela est similaire (mais distinct) d’autres travaux récents indépendants sur l’utilisation de circuits chiffrés pour BitVM (voir le Bulletin #359). Le post d’Eagen affirme “le premier (à son avis) verrou chiffré pratique dont la preuve de fraude est une unique signature, ce qui représente une réduction de plus de 550x des données onchain comparé à BitVM2.” À l’heure actuelle, son post n’a pas reçu de réponses publiques.

Questions et réponses sélectionnées de Bitcoin Stack Exchange

Bitcoin Stack Exchange est l’un des premiers endroits où les contributeurs d’Optech cherchent des réponses à leurs questions—ou quand nous avons quelques moments libres pour aider les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en lumière certaines des questions et réponses les mieux votées postées depuis notre dernière mise à jour.

• ● Est-il possible de récupérer une clé privée à partir d’une clé publique agrégée sous de fortes hypothèses ? Pieter Wuille explique les hypothèses de sécurité actuelles et hypothétiques autour de MuSig2 des multisignatures sans script.

• ● Toutes les adresses taproot sont-elles vulnérables au calcul quantique ? Hugo Nguyen et Murch soulignent que même les sorties taproot construites pour être dépensées uniquement en utilisant des chemins de script sont vulnérables quantiques. Murch note ensuite “de façon intéressante, la partie qui a déjà ajouté le support pour les transactions de splicing permet aux nœuds du réseau Lightning de rajouter ou de retirer des fonds d’un canal Lightning sans avoir à fermer et à rouvrir un nouveau canal, rendant ainsi les canaux plus flexibles et moins coûteux à gérer.

• ● Pourquoi ne pouvons-nous pas définir la clé d’obfuscation chainstate ? Ava Chow souligne que la clé qui obfusque le contenu sur disque du blocksdir (voir le Bulletin #339) n’est pas la même clé qui obfusque le contenu du chainstate (voir Bitcoin Core #6650).

• ● Est-il possible de révoquer une branche de dépense après une hauteur de bloc ? Antoine Poinsot pointe vers une réponse précédente confirmant que les conditions de dépense expirantes, ou “inverse timelocks”, ne sont pas possibles et peut-être même pas souhaitables.

• ● Configurer Bitcoin Core pour utiliser des nœuds onion en plus des nœuds IPv4 et IPv6 ? Pieter Wuille clarifie que la configuration de l’option onion s’applique uniquement aux connexions de pairs sortantes. Il explique ensuite comment configurer Tor et bitcoind pour les connexions entrantes.

Mises à jour et versions candidates

Nouvelles versions et versions candidates pour des projets d’infrastructure Bitcoin populaires. Veuillez envisager de mettre à niveau vers les nouvelles versions ou d’aider à tester les versions candidates.

• ● Bitcoin Core 29.1rc2 est un candidat à la sortie pour une version de maintenance du logiciel de nœud complet prédominant.

• ● Core Lightning v25.09rc4 est un candidat à la sortie pour une nouvelle version majeure de cette implémentation populaire de nœud LN.

Changements notables dans le code et la documentation

Changements notables récents dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Propositions d’Amélioration de Bitcoin (BIPs), Lightning BOLTs, Lightning BLIPs, Inquisition Bitcoin, et BINANAs.

• ● Bitcoin Core #31802 active par défaut la communication inter-processus (IPC) (ENABLE_IPC), ajoutant les binaires multiprocess bitcoin-node et bitcoin-gui aux builds de sortie sur tous les systèmes sauf Windows. Cela permet à un service de minage externe Stratum v2 qui crée, gère et soumet des modèles de blocs d’expérimenter avec la disposition multiprocess sans builds personnalisés. Pour plus de contexte sur le projet multiprocess et le binaire bitcoin-node, voir les Bulletins #99, #147, #320, #323.

• ● LDK #3979 ajoute le support de splice-out, permettant à un nœud LDK d’initier une transaction de splice-out, et d’accepter les demandes d’une contrepartie. Ceci complète l’implémentation du splicing par LDK, comme LDK #3736 avait déjà ajouté le support de l’ajout de séquence (splice-in). Cette PR ajoute une énumération SpliceContribution qui couvre les scénarios d’ajout et de retrait de séquence et garantit que les valeurs de sortie d’une transaction de retrait de séquence (splice-out) ne dépassent pas le solde du canal de l’utilisateur après avoir pris en compte les frais et les exigences de réserve.

• ● LND #10102 ajoute une option gossip.ban-threshold (100 est la valeur par défaut, 0 le désactive) qui permet aux utilisateurs de configurer le seuil de score à partir duquel un pair est banni pour avoir envoyé des messages de gossip invalides. Le système d’exclusion de pairs avait été introduit précédemment et décrit dans le Bulletin #319. Cette PR résout également un problème où des messages d’annonce de nœud et de canal inutiles étaient envoyés en réponse à une demande de requête de gossip en attente.

• ● Rust Bitcoin #4907 introduit le marquage de script en ajoutant un nouveau paramètre générique de tag T à Script et ScriptBuf, et définit les alias de type ScriptPubKey, ScriptSig, RedeemScript, WitnessScript, et TapScript qui sont soutenus par un trait Tag scellé pour la sécurité des rôles à la compilation.