Le bulletin de cette semaine transmet un préavis d’une prochaine version de sécurité de Core Lightning, résume une discussion sur la protection contre la relecture par adhésion volontaire pour de potentiels futurs forks, note que le projet Hardware Wallet Interface (HWI) passera en mode maintenance, et décrit une demande de commentaires sur l’utilisation de filtres par plage de blocs. Sont également incluses nos rubriques habituelles annonçant les nouvelles versions et versions candidates et décrivant les changements notables dans des logiciels populaires d’infrastructure Bitcoin.

Éléments d’action

  • ● Préparez-vous à une prochaine version de sécurité de Core Lightning : Christian Decker a décrit une prochaine version de sécurité corrective CLN v26.06.7, en notant qu’aucune vulnérabilité n’est connue pour être activement exploitée. Le projet prévoit une publication sous embargo dans environ 24 heures, en publiant les binaires mais en retenant le code source pendant 14 jours afin de ralentir tout attaquant cherchant à rétroconcevoir les correctifs. Une fois le code source rendu disponible, le système de build reproductible de CLN permettra aux utilisateurs de vérifier que les binaires correspondent au code source. Les opérateurs qui préfèrent attendre que le code source soit disponible pour effectuer la mise à jour devraient redémarrer avec l’option --offline (qui empêche le nœud d’établir ou d’accepter des connexions de pairs tout en conservant l’application onchain contre d’éventuels pairs tricheurs).

Nouvelles

  • ● Discussion sur une protection universelle contre la relecture par adhésion volontaire : Moonsettler a publié sur Delving Bitcoin pour discuter de la possibilité d’introduire un mécanisme de protection contre la relecture par adhésion volontaire en cas de futurs forks. L’idée faisait suite à des événements récents dans lesquels une chaîne minoritaire a fait l’objet d’attaques par relecture, un type d’attaque dans lequel une transaction signée valide sur une branche d’un fork est rediffusée sur l’autre, dépensant involontairement les pièces équivalentes sur les deux réseaux. L’auteur propose d’utiliser l’annexe taproot en y engageant une charge utile de 34 octets qui inclut le hash du bloc précédent (c.-à-d. <0xFAF0><32-byte-prior-block-hash>).

    La discussion s’est poursuivie avec Anthony Towns proposant d’utiliser à la place la hauteur du bloc et un suffixe du hash du bloc, afin de réduire la quantité de données à 6 octets. Moonsettler a accepté l’approche et a ajouté qu’il serait utile que les nœuds annotent les UTXO avec l’engagement de bloc afin de fournir cette information aux utilisateurs. L’auteur a également proposé une limite sur la profondeur des nouveaux engagements, idéalement la hauteur assumevalid, et que les nœuds conservent la trace de l’engagement jusqu’à 100 blocs. De plus, Towns a proposé d’ajouter un mécanisme similaire à une contrainte de maturité en définissant un nLocktime explicite pour empêcher qu’une transaction soit minée avant un certain nombre de blocs afin de tenir compte des réorganisations de blocs.

  • ● Le dépôt HWI passera en mode maintenance : Ava Chow (achow101) a annoncé que le projet Hardware Wallet Interface (HWI) réduira son activité à de la maintenance uniquement et sera finalement archivé. HWI, qui permet à Bitcoin Core et à d’autres logiciels de communiquer avec des dispositifs matériels de signature, a été développé presque entièrement par une seule personne et a reçu peu de nouveau développement depuis plusieurs années. Chow a déclaré qu’il avait atteint l’essentiel de son objectif initial consistant à apporter le support des portefeuilles matériels à Bitcoin Core, mais que sa base de code Python l’avait freiné dans cet objectif, puisqu’elle ne peut pas être buildée de manière reproductible et regroupée avec Bitcoin Core.

    Avant d’entrer en mode maintenance, le projet terminera son support de MuSig2 actuellement en cours et publiera ce qui devrait être sa dernière version. Il cessera d’accepter de nouvelles fonctionnalités et le support d’appareils supplémentaires, à l’exception de MuSig2. Chow a cité BHWI, une implémentation Rust en cours de développement de Wizardsardine, comme remplaçant potentiel.

  • ● Demande de commentaires sur l’utilisation de filtres par plage de blocs : Optout a publié sur Delving Bitcoin une demande de commentaires (RFC) sur une proposition visant à utiliser des filtres par plage de blocs pour réduire la taille totale de téléchargement lors de l’utilisation de filtres de blocs compacts. Au lieu de télécharger tous les filtres de blocs individuels, des filtres pour des plages de blocs pourraient être créés. Si un script est trouvé à l’intérieur de l’une de ces plages, les filtres de blocs individuels sont téléchargés et le processus fonctionne comme décrit dans BIP157. Bien que les filtres de plage et de blocs soient tous deux téléchargés pour les plages correspondantes, des économies de taille sont obtenues en évitant de télécharger tous les filtres de blocs dans les autres plages.

    Les résultats préliminaires semblent prometteurs. L’auteur a exécuté des simulations en utilisant différentes tailles de plage sur des données simulées d’environ 30k blocs. Deux ensembles différents de scripts ont été utilisés, l’un avec un très faible nombre de transactions (4-6 transactions) et l’autre avec un nombre plus élevé (20-30 transactions). La taille totale des filtres par plage de blocs diminue à mesure que la plage augmente. Cependant, la plupart des économies sont annulées lorsqu’on augmente trop la plage. Selon l’auteur, le meilleur compromis semble être trouvé avec une plage de 256 blocs, ce qui a réduit la taille totale de téléchargement d’environ 70–80 % pour les ensembles de scripts testés.

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.

  • ● BTCPay Server 2.4.3 est une version de sécurité de ce processeur de paiement auto-hébergé. Les utilisateurs sont encouragés à effectuer la mise à niveau, surtout si leurs serveurs sont partagés entre plusieurs utilisateurs.

  • ● Eclair 0.14.2 est une version de sécurité pour cette implémentation de nœud LN. Elle corrige des bogues d’échec de paiement et de gestion de canaux (voir le Bulletin #418), des vérifications manquantes de réserve de canal (voir le Bulletin #419), et des problèmes de financement à la volée (voir le Bulletin #419). Elle limite également les ressources consommées par les requêtes de gossip (voir le Bulletin #419) et les connexions entrantes en attente, et inclut des modifications de configuration des messages onion et de Tor. La mise à niveau est fortement recommandée car des nœuds malveillants pourraient exploiter certains des bogues corrigés. Les opérateurs devraient exécuter bitcoind sur la même machine qu’Eclair ou se connecter via un tunnel chiffré et authentifié, et consulter les notes de version pour les changements de configuration.

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 #34075 incorpore un estimateur de taux de frais basé sur le mempool à côté de l’estimateur existant de politique de bloc basé sur les confirmations. Le nouvel estimateur utilise les taux de frais par chunk au milieu et au dernier quartile du bloc suivant pour des estimations conservatrices et économiques, respectivement. S’il y a trop peu de transactions en attente de confirmation, il revient à la plus élevée entre le taux de frais minimal de relais et le taux de frais minimal du mempool. Par défaut, estimatesmartfee renvoie désormais la plus basse des estimations du mempool et de politique de bloc, de sorte que les conditions du mempool peuvent abaisser les estimations de taux de frais mais pas les augmenter. La nouvelle option fee_rate_estimator peut être utilisée pour obtenir des estimations basées sur une seule des approches.

  • ● Bitcoin Core #35730 ajoute une option de configuration -rpcmaxconnections (par défaut 16), qui limite le nombre de clients pouvant se connecter simultanément à son serveur HTTP (voir le Bulletin #411). Une fois la limite atteinte, les connexions supplémentaires restent dans la file d’attente des sockets du système d’exploitation sans consommer de mémoire applicative jusqu’à ce qu’un emplacement devienne disponible. Bitcoin Core peut désormais limiter et suivre l’utilisation des descripteurs de fichiers de ces connexions, résolvant un problème de longue date dans lequel une utilisation intensive de RPC pouvait épuiser les descripteurs de fichiers disponibles, provoquant l’échec d’opérations non liées. Ce changement améliore également la gestion des connexions en acceptant toutes les connexions en file d’attente jusqu’à la limite lors de chaque itération de la boucle d’E/S, au lieu de n’accepter qu’une seule connexion par itération.

  • ● Bitcoin Core #35580 corrige un bogue de construction de modèle de bloc qui comparait le poids ajusté selon les sigops d’un chunk de transaction (voir le Bulletin #416), plutôt que son poids réel BIP141, au poids maximal du bloc. Le poids ajusté selon les sigops classe les chunks selon leur taux de frais effectif, tandis que la validité du bloc contraint séparément le poids réel et le coût en sigops. Par conséquent, le comportement précédent pouvait exclure à tort un chunk dense en sigops avec un taux de frais élevé même lorsqu’il satisfaisait les deux limites, réduisant ainsi les revenus de minage.

  • ● Bitcoin Core #35665, #36025, et #35516 corrigent plusieurs problèmes lors de la combinaison ou de la jonction de PSBT. Le premier correctif traite un problème lors de la fusion de deux enregistrements xpub globaux. Auparavant, Bitcoin Core regroupait les enregistrements par origine de clé (empreinte et chemin de dérivation), même si la sérialisation PSBT les identifie par xpub. Il en résultait que le même xpub avec des origines conflictuelles était sérialisé sous forme de clés dupliquées, créant un PSBT invalide que le RPC decodepsbt rejette. La deuxième PR corrige le décalage analogue pour les enregistrements tapscript, qui sont regroupés en interne par script en feuille mais sérialisés par bloc de contrôle. Auparavant, la fusion pouvait créer des clés dupliquées lorsqu’un bloc de contrôle était associé à différents scripts, ou elle pouvait écarter des blocs de contrôle valides pour le même script. La troisième PR résout le problème du RPC joinpsbts qui supprimait les enregistrements xpub globaux et les métadonnées en mélangeant le PSBT fusionné sur place plutôt qu’en construisant un PSBT mélangé distinct qui omet certaines métadonnées globales.

  • ● Bitcoin Core #35933 et #34697 corrigent plusieurs problèmes de traitement PSBT de MuSig2 et de descripteurs. La première PR empêche des métadonnées de dérivation MuSig2 invalides ou incohérentes de provoquer l’abandon des RPC analyzepsbt, finalizepsbt, et descriptorprocesspsbt. La dérivation publique renforcée échoue désormais normalement tandis qu’une clé agrégée non correspondante est ignorée afin qu’une autre clé correspondante puisse être essayée. La deuxième PR améliore la détection des clés dupliquées dans les descripteurs en utilisant les informations disponibles sur les clés privées pour comparer les expressions de clés avec dérivation renforcée lors de l’analyse des descripteurs. Auparavant, différentes expressions pouvaient toutes deux échouer à être résolues et être faussement traitées comme des doublons, ce qui rejetait des descripteurs musig() valides qui réutilisent les mêmes participants avec des chemins de dérivation différents. Elle empêche également que l’origine de clé d’un participant MuSig2 réutilisé soit préfixée deux fois aux métadonnées de dérivation taproot stockées dans un PSBT.

  • ● Core Lightning #9374 corrige une erreur d’état de canal qui pouvait survenir lorsqu’une tentative antérieure de RBF pour un canal financé par les deux parties se confirmait à la place de la tentative la plus récente (voir le Bulletin #418 pour un bogue similaire sur Eclair). Auparavant, si le pair se reconnectait pendant que Core Lightning était encore en train de rattraper la blockchain, il pouvait supposer que la dernière tentative de RBF était celle qui s’était confirmée et verrouiller le canal sur une transaction de financement non confirmée. Désormais, Core Lightning enregistre la tentative de financement qui s’est effectivement confirmée dès que son bloc est traité et utilise cette tentative lors du rétablissement du canal.

  • ● Eclair #3342 implémente le bit de fonctionnalité option_onion_messages_only_channels spécifié dans BOLTs #1343 (voir le Bulletin #416). Lorsqu’il est configuré pour relayer des messages onion uniquement pour des pairs avec des canaux, Eclair annonce désormais ce bit de fonctionnalité. Lorsqu’il relaie pour tous les pairs, Eclair annonce le bit de fonctionnalité option_onion_messages.

  • ● Eclair #3321 implémente le support du champ optionnel fulfillment_payload ajouté au message update_fulfill_htlc tel que spécifié par BOLTs #1344, étendant les échecs attribuables aux paiements réussis (voir le Bulletin #416). Eclair peut relayer les charges utiles d’acquittement et les authentifier comme faisant partie des données d’attribution, et peut les déchiffrer lorsqu’il est le payeur, mais n’en génère pas encore lorsqu’il est le destinataire du paiement. La PR signale une interopérabilité avec LDK, qui avait précédemment ajouté des données d’attribution au chemin des paiements réussis (voir le Bulletin #364).

  • ● LND #11008 corrige un problème d’interblocage dans le flux d’ouverture de canal PSBT de LND. Auparavant, si la vérification du financement PSBT et le nettoyage d’une réservation de canal annulée s’exécutaient en même temps, chaque opération pouvait attendre des ressources détenues par l’autre. Cela pouvait bloquer l’unique gestionnaire de réservations de LND, empêchant le nœud d’ouvrir ou d’accepter des canaux et laissant les canaux nouvellement financés bloqués jusqu’à un redémarrage. Le correctif modifie l’ordre dans lequel l’état partagé est consulté, empêchant les deux opérations de se bloquer mutuellement indéfiniment.

  • ● HWI #841 étend la commande displayaddress pour afficher sur un appareil matériel une adresse pour une politique de descripteur de portefeuille BIP388 enregistrée, sélectionnée par index d’adresse et branche de réception ou de monnaie. La commande accepte les informations d’enregistrement renvoyées par la commande registerdescriptor et ajoute le support des appareils BitBox02, Coldcard, Jade, et Ledger, en s’appuyant sur le support d’enregistrement de descripteurs décrit dans le Bulletin #419.

  • ● HWI #849 met à jour le support de Coldcard pour afficher des adresses taproot à signature unique sur les appareils Coldcard Edge. Il préserve également le format PSBTv2 lors de la signature avec un firmware Coldcard qui le prend en charge, au lieu de toujours convertir le PSBT en version 0. La PR ajoute une couverture du simulateur Coldcard Edge, rétablit les tests de signature de transaction à signature unique, et met à jour le firmware Coldcard testé vers la version 5.6.0.

  • ● Rust Bitcoin #6755 corrige la vérification des signatures segwit v0 pour les transactions utilisant des valeurs de hash de signature ECDSA (sighash) non standard mais valides du point de vue du consensus. Auparavant, EcdsaSighashType associait ces valeurs à des types sighash standard au comportement équivalent ALL, NONE, SINGLE, et ANYONECANPAY, perdant la valeur d’origine. Comme la valeur exacte est également incluse dans le hash de signature segwit v0, cela pouvait conduire Rust Bitcoin à calculer un mauvais sighash et à échouer à vérifier les signatures de transactions valides du point de vue du consensus et déjà confirmées. La nouvelle représentation préserve la valeur d’origine, tandis que les appelants qui ont besoin de types sighash standard peuvent continuer à utiliser from_standard (voir le Bulletin #138).