La newsletter de cette semaine résume une vulnérabilité affectant d’anciennes versions de LND, décrit une idée pour améliorer la confidentialité lors de l’utilisation de services de co-signataires, et examine l’impact du passage à des algorithmes de signature résistants aux quantiques sur les portefeuilles HD, le multisig sans script, et les paiements silencieux. 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

  • ● Vulnérabilité de DoS du filtre de gossip de LND : Matt Morehouse a publié sur Delving Bitcoin concernant une vulnérabilité affectant les versions passées de LND qu’il avait précédemment divulguée de manière responsable. Un attaquant pourrait demander à répétition des messages de l’historique de gossip à un nœud LND jusqu’à ce qu’il manque de mémoire et se coupe. La vulnérabilité a été corrigée dans LND 0.18.3, publié en septembre 2024.

  • ● Rétention du code de chaîne pour les scripts multisig : Jurvis Tan a posté sur Delving Bitcoin à propos de recherches qu’il a effectuées avec Jesse Posner pour améliorer la confidentialité et la sécurité de la garde collaborative multisig. Dans un service de garde collaborative typique, un multisig 2-sur-3 peut être utilisé avec les trois clés étant :

    • Une clé chaude utilisateur qui est stockée sur un appareil connecté au réseau et signe les transactions pour l’utilisateur (soit manuellement, soit par automatisation logicielle).

    • Une clé chaude du fournisseur qui est stockée sur un appareil connecté au réseau séparé sous le contrôle exclusif du fournisseur. La clé ne signe les transactions selon une politique précédemment définie par l’utilisateur, comme permettant seulement des dépenses jusqu’à x BTC par jour.

    • Une clé froide utilisateur qui est stockée hors ligne et est utilisée seulement si la clé chaude de l’utilisateur est perdue ou si le fournisseur cesse de signer les transactions autorisées.

    Bien que la configuration ci-dessus puisse fournir un renforcement significatif de la sécurité, la méthode de configuration presque toujours utilisée implique que l’utilisateur partage avec le fournisseur les clés publiques étendues BIP32 pour les portefeuilles chaud et froid de l’utilisateur. Cela permet au fournisseur de détecter tous les fonds reçus par le portefeuille de l’utilisateur et de suivre toutes les dépenses de ces fonds même si l’utilisateur dépense sans l’assistance du fournisseur. Plusieurs moyens de mitiger cette perte de confidentialité ont été précédemment décrits, mais ils sont soit incompatibles avec l’utilisation typique (par exemple, en utilisant des tapleaves distinctes) soit complexes (par exemple, nécessitant MPC). Tan et Posner décrivent une alternative simple :

    • Le fournisseur génère la moitié d’une clé étendue HD BIP32 (juste la partie clé). Ils donnent la clé publique à l’utilisateur.

    • L’utilisateur génère l’autre moitié (le code de chaîne). Ils gardent cela privé.

    Lors de la réception de fonds, l’utilisateur peut combiner les deux moitiés pour créer une clé publique étendue (xpub) puis dériver des adresses multisig comme d’habitude. Le fournisseur ne connaissant pas le code de chaîne, il est empêché de dériver l’xpub ou de découvrir l’adresse.

    Lors de la dépense de fonds, l’utilisateur peut dériver du code de chaîne avec l’ajustement nécessaire que le fournisseur doit combiner avec sa clé privée pour créer une signature valide. Ils partagent simplement cet ajustement avec le fournisseur. Le fournisseur ne peut rien apprendre de l’ajustement, sauf qu’il est valide pour dépenser depuis le scriptPubKey spécifique qui a reçu des fonds.

    Certains fournisseurs peuvent exiger que la sortie de monnaie rendue d’une transaction de dépense renvoie l’argent au même modèle de script. Le post de Tan décrit comment cela peut être facilement accompli.

  • ● La recherche indique que les primitives Bitcoin communes sont compatibles avec les algorithmes de signature résistants aux quantiques : Jesse Posner a posté sur Delving Bitcoin plusieurs liens vers des articles de recherche qui indiquent que les algorithmes de signature résistants aux quantiques fournissent des primitives comparables à celles actuellement utilisées dans Bitcoin pour les portefeuilles HD BIP32, les adresses de paiement silencieuses, les multisignatures sans script, et les signatures de seuil sans script.

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.

Mises à jour et versions candidates

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

  • ● Libsecp256k1 v0.7.0 est une sortie de cette bibliothèque contenant des primitives cryptographiques compatibles avec Bitcoin. Elle contient quelques petits changements qui rompent la compatibilité API/ABI avec les versions précédentes.

Changements notables dans le code et la documentation

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

  • ● Bitcoin Core #32521 rend les transactions héritées avec plus de 2500 opérations de signature (sigops) non standard en préparation pour une potentielle mise à niveau de soft fork de nettoyage de consensus qui imposerait la limite au niveau du consensus. Si le soft fork avait lieu sans ce changement, les mineurs qui ne mettent pas à jour pourraient devenir des cibles d’attaques DoS triviales. Voir le Bulletin #340 pour plus de détails sur la limite des sigops d’entrée héritée.

  • ● Bitcoin Core #31829 ajoute des limites de ressources au gestionnaire de transactions orphelines, TxOrphanage (Voir le Bulletin #304), pour préserver le relais de paquets opportuniste un-parent-un-enfant (1p1c) face aux attaques de spam DoS. Quatre limites sont imposées : un plafond global de 3 000 annonces orphelines (pour minimiser le coût en CPU et en latence), un plafond d’annonces orphelines par pair proportionnel, une réservation de poids par pair de 24 × 400 kWU, et un plafond de mémoire global variable. Lorsqu’une limite est dépassée, le nœud évince l’annonce orpheline la plus ancienne du pair qui a utilisé le plus de CPU ou de mémoire par rapport à son allocation (score Peer DoS le plus élevé). La PR supprime également l’option ‑maxorphantxs (par défaut 100), dont la politique d’éviction d’annonces aléatoires permettait aux attaquants de remplacer l’ensemble des orphelins et de rendre le relais 1p1c inutile. Voir également le Bulletin #362.

  • ● LDK #3801 étend les échecs attribuables au chemin de réussite de paiement en enregistrant combien de temps un nœud détient un HTLC et en propageant ces valeurs de temps de détention en amont dans la charge utile d’attribution. Auparavant, LDK ne suivait les temps de détention que pour les paiements échoués (voir le Bulletin #349).

  • ● LDK #3842 étend sa machine d’état de construction de transaction interactive (Voir le Bulletin #295) pour gérer la coordination de signature pour les entrées partagées dans les transactions de splicing. Le champ prevtx du message TxAddInput est rendu optionnel pour réduire l’utilisation de la mémoire et simplifier la validation.

  • ● BIPs #1890 change le paramètre séparateur de + à - dans BIP77 parce que certaines bibliothèques URI HTML 2.0 traitent + comme s’il s’agissait d’un espace blanc. De plus, les paramètres de fragment doivent maintenant être ordonnés lexicographiquement, plutôt qu’à l’envers, pour simplifier le protocole payjoin asynchrone.

  • ● BOLTs #1232 rend le champ channel_type (voir le Bulletin #165) obligatoire lors de l’ouverture d’un canal car chaque implémentation l’impose. Cette PR met également à jour BOLT9 en ajoutant un nouveau type de contexte T pour les fonctionnalités qui peuvent être incluses dans le champ channel_type.