Le bulletin de cette semaine révèle des vulnérabilités dans LND et décrit un projet pour exécuter une machine virtuelle dans un élément sécurisé embarqué. Sont également incluses nos sections régulières décrivant les changements apportés aux services et aux logiciels clients, résumant les questions et réponses populaires du Bitcoin Stack Exchange, et examinant les récents changements apportés aux logiciels d’infrastructure Bitcoin populaires.

Nouvelles

  • Vulnérabilités critiques corrigées dans LND 0.19.0 : Matt Morehouse a publié sur Delving Bitcoin concernant des vulnérabilités critiques corrigées dans LND 0.19.0. Dans cette divulgation, trois vulnérabilités sont mentionnées, incluant une de déni de service (DoS) et deux de vol de fonds.

    • Vulnérabilité de DoS par épuisement de mémoire lors du traitement des messages : Cette vulnérabilité de DoS profitait du fait que LND autorisait autant de pairs qu’il y avait de descripteurs de fichiers disponibles. L’attaquant pouvait ouvrir de multiples connexions avec la victime et spammer des messages query_short_channel_ids de 64 Ko tout en maintenant la connexion ouverte jusqu’à ce que LND manque de mémoire. La mitigation pour cette vulnérabilité a été mise en œuvre dans LND 0.19.0 le 12 mars 2025.

    • Perte de fonds due à une nouvelle vulnérabilité de failback excessive : Cette attaque est une variante du bug de failback excessif, et bien que la correction originale pour le bug de failback ait été faite dans LND 0.18.0, une variante mineure subsistait lorsque le canal était fermé de force en utilisant l’engagement de LND au lieu de celui de l’attaquant. La mitigation pour cette vulnérabilité a été mise en œuvre dans LND 0.19.0 le 20 mars 2025.

    • Vulnérabilité de perte de fonds dans le balayage HTLC : Cette vulnérabilité de vol de fonds profitait des faiblesses du système de balayage de LND, permettant à un attaquant de bloquer les tentatives de LND de réclamer sur onchain les HTLC expirés. Après avoir bloqué pendant 80 blocs, l’attaquant pouvait alors voler essentiellement tout le solde du canal.

    Morehouse incite les utilisateurs à mettre à niveau vers LND 0.19.0 ou une version supérieure pour éviter le déni de service et la perte de fonds.

  • Un enclave sécurisé virtualisé pour les dispositifs de signature matérielle : Salvatoshi a publié sur Delving Bitcoin à propos de Vanadium, un enclave sécurisé virtualisé pour les dispositifs de signature matérielle. Vanadium est une machine virtuelle RISC-V, conçue pour exécuter des applications arbitraires, appelées “V-Apps”, dans un élément sécurisé embarqué, externalisant les besoins de mémoire et de stockage vers un hôte non fiable. Selon Salvatoshi, l’objectif de Vanadium est d’abstraire les complexités du développement embarqué, telles que la RAM et le stockage limités, les SDK spécifiques aux fournisseurs, les cycles de développement lents et le débogage, pour rendre l’innovation en auto-garde plus rapide, plus ouverte et standardisée.

    Salvatoshi note que, d’un point de vue performance, la machine virtuelle exécute uniquement la logique métier de l’application, tandis que les opérations lourdes (c.-à-d. la cryptographie) s’exécutent de manière native via des ECALLs. Bien que le modèle de menace soit le même que pour les portefeuilles matériels existants, Salvatoshi souligne que cette approche permet une fuite du schéma d’accès à la mémoire, où l’hôte peut observer quelles pages de code et de données sont accédées et quand. Cela est particulièrement important pour les développeurs en cryptographie.

    Le projet n’est toujours pas considéré comme prêt pour la production, et il existe certaines limitations connues, telles que la performance et l’expérience utilisateur (UX). Cependant, Salvatoshi a demandé aux développeurs de l’essayer et de fournir des retours pour établir la feuille de route du projet.

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.

  • Outil de visualisation de transactions interactif : RawBit est un outil de visualisation de transactions basé sur le web, open-source. Il propose des leçons interactives sur une variété de types de transactions avec des plans pour des leçons supplémentaires sur taproot, PSBTs, HTLCs, coinjoins, et des propositions de covenant.

  • BlueWallet v7.2.2 publié : La version 7.2.2 de BlueWallet ajoute le support pour les portefeuilles taproot, incluant l’envoi, la réception, le suivi seulement, le contrôle des pièces, et les fonctionnalités de signature avec dispositif matériel.

  • Mises à jour de Stratum v2 : Stratum v2 v1.6.0 réorganise les dépôts Stratum v2, ajoutant un dépôt sv2-apps et une version v.01 supportant la communication directe avec les nœuds Bitcoin Core 30.0 non modifiés utilisant IPC (voir le Bulletin #369). Les versions incluent également des outils web pour les mineurs et les développeurs pour les tests, parmi d’autres fonctionnalités.

  • Auradine annonce le support de Stratum v2 : Auradine a annoncé le support des fonctionnalités de Stratum v2 dans leurs mineurs.

  • LDK Node 0.7.0 publié : LDK Node 0.7.0 ajoute un support expérimental pour le splicing et le support pour servir et payer des factures statiques par paiements asynchrones, parmi d’autres fonctionnalités et corrections de bugs.

  • Librairie Python BIP-329 1.0.0 publiée : La version 1.0.0 de la Librairie Python BIP-329 prend en charge les champs supplémentaires de BIP329, incluant la validation type et la couverture des tests.

  • Bitcoin Safe 1.6.0 publié : La version 1.6.0 ajoute le support pour les filtres de blocs compacts et les constructions reproductibles.

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.

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, Bitcoin Inquisition, et BINANAs.

  • Bitcoin Core #33528 empêche le portefeuille de dépenser les sorties de transactions TRUC non confirmées ayant un ancêtre non confirmé, pour se conformer aux limites de politique TRUC. Auparavant, le portefeuille pouvait créer de telles transactions, mais elles étaient rejetées lors de la diffusion.

  • Bitcoin Core #33723 retire dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us de la liste des graines DNS. Les mainteneurs ont trouvé que c’était la seule graine qui omettait les nouvelles versions de Bitcoin Core (29 et 30), violant la politique stipulant que “les résultats des graines doivent consister exclusivement de nœuds Bitcoin sélectionnés de manière équitable et fonctionnant sur le réseau public”.

  • Bitcoin Core #33993 met à jour le texte d’aide pour l’option stopatheight, clarifiant que la hauteur cible spécifiée pour arrêter la synchronisation est seulement une estimation et que des blocs après cette hauteur peuvent encore être traités pendant l’arrêt.

  • Bitcoin Core #33553 ajoute un message d’avertissement indiquant une potentielle corruption de la base de données lorsque des en-têtes sont reçus pour des blocs qui étaient précédemment marqués comme invalide. Cela aide les utilisateurs à réaliser qu’ils pourraient être coincés dans une boucle de synchronisation d’en-tête. Cette PR active également un message d’avertissement de détection de fork qui était précédemment désactivé pour l’IBD.

  • Eclair #3220 étend le helper spendFromChannelAddress existant aux canaux taproot, ajoutant un endpoint spendfromtaprootchanneladdress qui permet aux utilisateurs de dépenser de manière coopérative les UTXOs envoyés accidentellement aux adresses de financement de canal taproot, avec des signatures MuSig2.

  • LDK #4231 arrête de fermer de force les canaux zero-conf lorsqu’une réorganisation de blocs déconfirme la transaction de financement du canal. LDK a un mécanisme pour fermer de force les canaux verrouillés qui deviennent non confirmés en raison du risque de double dépense. Cependant, le modèle de confiance est différent pour les canaux zero-conf. Le changement de SCID est également maintenant correctement géré dans ce cas limite.

  • LND #10396 renforce l’heuristique du routeur pour détecter les nœuds assistés par LSP : les factures avec un nœud de destination public ou dont les sauts de destination de l’indice de route sont tous privés sont maintenant traités comme des nœuds normaux, tandis que ceux avec une destination privée et au moins un saut de destination public sont classifiés comme soutenus par LSP. Auparavant, l’heuristique plus lâche pouvait mal classer les nœuds comme assistés par LSP, entraînant plus d’échecs de sondage. Maintenant, lorsqu’un nœud assisté par LSP est détecté, LND sonde jusqu’à trois LSP candidats et utilise l’itinéraire le plus défavorable (frais les plus élevés et CLTV) pour fournir des estimations de frais conservatrices.

  • BTCPay Server #7022 introduit une API pour la fonctionnalité Subscriptions (voir le Bulletin #379), permettant aux commerçants de créer et de gérer des offres, des plans, des abonnés et des checkouts. Environ une douzaine de points de terminaison ont été ajoutés pour chaque opération spécifique.

  • Rust Bitcoin #5379 ajoute une méthode pour construire des adresses Pay-to-Anchor (P2A), pour compléter la méthode existante de vérification des adresses P2A.

  • BIPs #2050 met à jour BIP390, qui spécifie les descripteurs MuSig2, pour permettre des expressions de clé musig() à l’intérieur d’un rawtr() en plus du tr() déjà autorisé, alignant la description avec les vecteurs de test existants et l’implémentation des descripteurs de Bitcoin Core.

Joyeuses fêtes !

Ceci est le dernier bulletin régulier de Bitcoin Optech de l’année. Le vendredi 19 décembre, nous publierons notre huitième bulletin de révision annuel. La publication régulière reprendra le vendredi 2 janvier.