Le bulletin de cette semaine relaie la divulgation responsable d’une vulnérabilité affectant d’anciennes implémentations de LN et évoque une synthèse des propositions d’opcodes pour les covenants. Sont également incluses nos sections régulières concernant les questions et réponses populaires sur le Bitcoin Stack Exchange, les nouvelles versions et les versions candidates, et les changements apportés aux principaux logiciels de l’infrastructure Bitcoin.

Nouvelles

  • ● Divulgation d’une vulnérabilité passée de LN liée au financement fictif : Matt Morehouse a publié sur la liste de diffusion Lighting-Dev le résumé d’une vulnérabilité qu’il avait précédemment divulguée de manière responsable et qui est maintenant résolue dans les dernières versions de toutes les implémentations LN populaires. Pour comprendre la vulnérabilité, imaginez que Bob exécute un nœud LN. Il reçoit une demande du nœud de Mallory pour ouvrir un nouveau canal et ils passent par le processus d’ouverture du canal jusqu’à l’étape où Mallory est censé diffuser une transaction qui finance le canal. Pour pouvoir utiliser ultérieurement ce canal, Bob doit stocker un certain état qui lui est lié et commencer à scanner de nouveaux blocs pour que la transaction soit suffisamment confirmée. Si Mallory ne diffuse jamais la transaction, les ressources de stockage et de numérisation de Bob sont gaspillées. Si Mallory répète le processus des milliers ou des millions de fois, cela pourrait gaspiller les ressources de Bob au point où son nœud LN ne peut plus rien faire—y compris effectuer des opérations sensibles au facteur temps nécessaires pour éviter la perte d’argent.

    Dans les tests de Morehouse sur ses propres nœuds, il a pu causer des problèmes importants avec Core Lightning, Eclair, LDK et LND, y compris deux cas qui (selon nous) pourraient probablement entraîner une perte de fonds parmi de nombreux nœuds. La description complète de Morehouse renvoie aux PR où le problème a été résolu (ce qui inclut les PR couverts dans les bulletins #237 et #240) et liste les versions LN qui ont résolu la vulnérabilité :

    • Core Lightning 23.02
    • Eclair 0.9.0
    • LDK 0.0.114
    • LND 0.16.0

    Il y a eu des discussions de suivi sur la liste de diffusion et sur IRC.

  • ● Synthèse de covenants utilisant TXHASH et CSFS : Brandon Black a publié sur la liste de diffusion Bitcoin-Dev une proposition pour une version de OP_TXHASH (voir Bulletin #185) combinée avec OP_CHECKSIGFROMSTACK qui fournirait la plupart des fonctionnalités de OP_CHECKTEMPLATEVERIFY (CTV) et de SIGHASH_ANYPREVOUT (APO) sans coût supplémentaire important par rapport à ces propositions individuelles. Bien que la proposition soit indépendante, une partie de la motivation pour la créer était de “clarifier notre réflexion sur [CTV et APO] individuellement et ensemble, et potentiellement de progresser vers un consensus sur une voie permettant […] des façons étonnantes d’utiliser le bitcoin à l’avenir”.

    La proposition a suscité des discussions sur la liste de diffusion, avec des révisions supplémentaires publiées et discutées sur le forum Delving Bitcoin.

Sélection de Q&R du Bitcoin Stack Exchange

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

Mises à jour et versions candidates

Nouvelles versions et versions candidates pour les principaux projets d’infrastructure Bitcoin. Veuillez envisager de passer aux nouvelles versions ou d’aider à tester les versions candidates.

  • ● Core Lightning 23.08 est la dernière version majeure de cette implémentation populaire de nœud LN. Les nouvelles fonctionnalités incluent la possibilité de modifier plusieurs paramètres de configuration du nœud sans redémarrer celui-ci, la prise en charge de la sauvegarde et de la restauration des semences au format Codex32, un nouveau plugin expérimental pour améliorer la recherche de chemin de paiement, la prise en charge expérimentale du splicing et la possibilité de payer des factures générées localement, parmi de nombreuses autres nouvelles fonctionnalités et corrections de bugs.

  • ● LND v0.17.0-beta.rc1 est un candidat à la prochaine version majeure de cette implémentation populaire de nœud LN. Une nouvelle fonctionnalité expérimentale majeure prévue pour cette version, qui pourrait bénéficier de tests, est la prise en charge des “canaux taproot simples” tels que décrits dans la PR LND #7904, dans la section des changements notables.

Changements notables dans le code et la documentation

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

  • ● Bitcoin Core #27460 ajoute une nouvelle RPC importmempool. La RPC chargera un fichier mempool.dat et tentera d’ajouter les transactions chargées à sa mempool.

  • ● LDK #2248 fournit un système intégré que les projets dérivés de LDK peuvent utiliser pour suivre les UTXO référencés dans les messages de gossip. Les nœuds LN qui traitent les messages de gossip ne doivent accepter que les messages signés par une clé associée à un UTXO, sinon ils peuvent être contraints de traiter et de relayer des messages indésirables, ou de tenter de transférer des paiements sur des canaux inexistants (ce qui échouera toujours). Le nouveau UtxoSource intégré fonctionne pour les nœuds LN connectés à un Bitcoin Core local.

  • ● LDK #2337 facilite l’utilisation de LDK pour construire des watchtowers qui fonctionnent de manière indépendante du portefeuille de l’utilisateur mais peuvent recevoir des transactions de pénalité LN chiffrées depuis le nœud de l’utilisateur. Une tour de guet peut ensuite extraire des informations de chaque transaction dans les nouveaux blocs et utiliser ces informations pour tenter de décrypter les données précédemment reçues. Si le décryptage réussit, la tour de guet peut diffuser la transaction de pénalité décryptée. Cela protège l’utilisateur contre la publication d’un état de canal révoqué par la contrepartie lorsque l’utilisateur est indisponible.

  • ● LDK #2411 et #2412 ajoutent une API pour construire des chemins de paiement pour les paiements aveugles. Les PR aident à séparer le code de LDK pour les messages oignon (qui utilisent des chemins aveugles) des chemins aveugles eux-mêmes. Un suivi dans #2413 ajoutera en fait la prise en charge de l’aveuglement des itinéraires.

  • ● LDK #2507 ajoute une solution de contournement pour un problème de longue date dans une autre implémentation qui entraîne des fermetures de canal forcées inutiles.

  • ● LDK #2478 ajoute un événement qui fournit des informations sur un HTLC transféré qui a maintenant été réglé, y compris le canal d’origine, le montant du HTLC et le montant des frais collectés.

  • ● LND #7904 ajoute une prise en charge expérimentale des “canaux taproot simples”, permettant aux transactions de financement et d’engagement LN d’utiliser P2TR avec prise en charge de la signature MuSig2 sans script multisignature lorsque les deux parties coopèrent. Cela réduit l’espace de poids des transactions et améliore la confidentialité lorsque les canaux sont fermés de manière coopérative. LND continue d’utiliser exclusivement des HTLC, permettant aux paiements commençant dans un canal taproot de continuer à être transférés via d’autres nœuds LN qui ne prennent pas en charge les canaux taproot.

    Ce PR comprend 134 validations qui ont été précédemment fusionnées dans une branche d’essai à partir des PR suivants : #7332, #7333, #7331, #7340, #7344, #7345, #7346, #7347 et #7472.