Le bulletin de cette semaine inclut nos sections habituelles décrivant les changements apportés aux services et aux logiciels clients, annonçant des mises à jour et des versions candidates, et résumant les changements récents apportés aux logiciels d’infrastructure Bitcoin populaires.

Nouvelles

Aucune nouvelle significative cette semaine n’a été trouvée dans aucune de nos sources.

Changements dans les services et les logiciels clients

Dans cette rubrique mensuelle, nous mettons en lumière des mises à jour intéressantes des portefeuilles et services Bitcoin.

Mises à jour et versions candidates

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

  • ● LND 0.19.0-beta est la dernière version majeure de ce nœud LN populaire. Elle contient de nombreuses améliorations et corrections de bugs, y compris le nouveau bumping de frais basé sur RBF pour les fermetures coopératives.

  • ● Core Lightning 25.05rc1 est un candidat à la sortie pour la prochaine version majeure de cette implémentation de nœud LN populaire.

Changements notables dans le code et la documentation

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

  • ● Bitcoin Core #32423 supprime l’avis de dépréciation pour rpcuser/rpcpassword et le remplace par un avertissement de sécurité concernant le stockage des identifiants en clair dans le fichier de configuration. Cette option avait été initialement dépréciée lorsque rpcauth a été introduit dans Bitcoin Core #7044, qui prend en charge plusieurs utilisateurs RPC et hache son cookie. La PR ajoute également un grain de sel aléatoire de 16 octets aux identifiants des deux méthodes et les hash avant qu’ils ne soient stockés en mémoire.

  • ● Bitcoin Core #31444 étend la classe TxGraph (voir le Bulletin #348) avec trois nouvelles fonctions d’aide : GetMainStagingDiagrams() retourne les divergences de clusters entre les diagrammes de taux de frais principaux et de mise en scène, GetBlockBuilder() itère à travers des morceaux de graphique (groupements triés par taux de frais en sous-cluster) du plus élevé au plus bas taux de frais pour une construction de bloc optimisée, et GetWorstMainChunk() identifie le morceau au taux de frais le plus bas pour les décisions d’éviction. Cette PR est l’un des derniers éléments de construction de l’implémentation initiale complète du projet de mempool en cluster.

  • ● Core Lightning #8140 active le stockage par les pairs des sauvegardes de canaux par défaut (voir le Bulletin #238), le rendant viable pour les grands nœuds en limitant le stockage aux pairs ayant des canaux actuels ou passés, en mettant en cache les sauvegardes et les listes de pairs en mémoire au lieu de faire des appels répétés à listdatastore/listpeerchannels, en plafonnant les téléchargements de sauvegarde concurrents à deux pairs, en sautant les sauvegardes de plus de 65 kB, et en randomisant la sélection des pairs lors de l’envoi.

  • ● Core Lightning #8136 met à jour l’échange de signatures d’annonce pour qu’il se produise lorsque le canal est prêt plutôt qu’après six blocs, pour s’aligner sur la récente mise à jour de la spécification BOLTs #1215. Il est toujours nécessaire d’attendre six blocs pour annoncer le canal.

  • ● Core Lightning #8266 ajoute une commande update au gestionnaire de plugins Reckless (voir le Bulletin #226) qui met à jour un plugin spécifié ou tous les plugins installés si aucun n’est spécifié, à l’exception de ceux installés à partir d’un tag Git fixe ou d’un commit. Cette PR étend également la commande install pour prendre un chemin source ou une URL en plus d’un nom de plugin.

  • ● Core Lightning #8021 finalise l’interopérabilité de splicing avec Eclair (voir le Bulletin #331) en corrigeant la rotation des clés de financement à distance, en renvoyant splice_locked lors du réétablissement du canal pour couvrir les cas où il était initialement manqué (voir le Bulletin #345), en assouplissant l’exigence que les messages signés d’engagement arrivent dans un ordre particulier, permettant de recevoir et d’initier des transactions de raccordement RBF, convertissant automatiquement les PSBTs sortants en version 2 lorsque nécessaire, ainsi que d’autres modifications de refactoring.

  • ● Core Lightning #8226 implémente BIP137 en ajoutant une nouvelle commande RPC signmessagewithkey qui permet aux utilisateurs de signer des messages avec n’importe quelle clé du portefeuille en spécifiant une adresse Bitcoin. Auparavant, signer un message avec une clé Core Lightning nécessitait de trouver le xpriv et l’index de la clé, de dériver la clé privée avec une bibliothèque externe, puis de signer le message avec Bitcoin Core.

  • ● LND #9801 ajoute une nouvelle option --no-disconnect-on-pong-failure, qui contrôle si un pair est déconnecté si une réponse pong est tardive ou ne correspond pas. Cette option est définie sur false par défaut, préservant le comportement actuel de LND qui se déconnecte d’un pair en cas d’échec du message pong (voir le Bulletin #275) ; autrement, LND ne ferait que consigner l’événement. La PR refactorise le chien de garde ping pour continuer sa boucle lorsque la déconnexion est supprimée.