Le bulletin de cette semaine annonce la divulgation d’une vulnérabilité affectant d’anciennes versions de LND et résume la discussion continue sur les PSBT pour les paiements silencieux. Nous incluons également nos sections régulières décrivant les mises à jour des clients et des services, les nouvelles versions et les versions candidates, ainsi que les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

  • ● Divulgation d’une vulnérabilité affectant d’anciennes versions de LND : Matt Morehouse a divulgué sur Delving Bitcoin une vulnérabilité affectant les versions de LND antérieures à 0.17.0. LN relaie les instructions de paiement et les messages en onion en utilisant des paquets chiffrés en onion qui contiennent plusieurs charges utiles chiffrées. Chaque charge utile est précédée de sa longueur, qui depuis 2019 a été autorisée à être de n’importe quelle taille jusqu’à 1 300 octets pour les paiements. Les messages en onion, introduits plus tard, peuvent mesurer jusqu’à 32 768 octets. Cependant, le préfixe de taille de la charge utile utilise un type de données qui permet d’indiquer une taille jusqu’à 264 octets.

    LND acceptait une taille indiquée pour la charge utile jusqu’à 4 gigaoctets et allouerait cette quantité de mémoire avant de traiter davantage de charge utile. Cela suffit pour épuiser la mémoire de certains nœuds LND, entraînant leur crash ou leur terminaison par le système d’exploitation, et cela pourrait être utilisé pour faire crasher des nœuds ayant plus de mémoire en envoyant plusieurs paquets en onion construits de cette manière. Un nœud LN en crash ne peut pas envoyer des transactions sensibles au temps qui peuvent être nécessaires pour protéger ses fonds, potentiellement conduisant au vol de fonds.

    La vulnérabilité a été corrigée en réduisant l’allocation mémoire maximale à 65 536 octets.

    Toute personne exploitant un nœud LND devrait mettre à niveau vers la version 0.17.0 ou supérieure. La mise à niveau vers la dernière version (0.18.0 au moment de la rédaction) est toujours recommandée.

  • ● Discussion continue sur les PSBT pour les paiements silencieux : plusieurs développeurs ont discuté de l’ajout du support pour coordonner l’envoi de paiements silencieux en utilisant des PSBT. Depuis notre résumé précédent, la discussion a porté sur l’utilisation d’une technique où chaque signataire génère une partage ECDH et une preuve compacte qu’ils ont généré leur part correctement. Celles-ci sont ajoutées à la section d’entrée du PSBT. Lorsque les parts de tous les signataires sont reçues, elles sont combinées avec la clé de scan de paiement silencieux du destinataire pour produire la clé réelle placée dans le script de sortie (ou plusieurs clés avec plusieurs scripts de sortie si plusieurs paiements silencieux sont effectués dans la même transaction).

    Une fois que les scripts de sortie de la transaction sont connus, chaque signataire re-traite le PSBT pour ajouter leurs signatures. Cela résulte en un processus en deux étapes pour la signature complète du PSBT (en plus de tout autre tour requis par d’autres protocoles, tels que MuSig2). Cependant, s’il n’y a qu’un seul signataire pour l’ensemble de la transaction, (par exemple, le PSBT est envoyé à un seul appareil de signature matériel), le processus de signature peut être complété en un seul tour.

    Tous les participants actifs à la discussion au moment de la rédaction semblent globalement d’accord sur cette approche, bien que la discussion sur les cas particuliers continue.

Modifications apportées aux services et aux logiciels clients

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

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.

  • ● Bitcoin Core 26.2rc1 est un candidat à la sortie pour une version de maintenance de Bitcoin Core pour les utilisateurs qui ne peuvent pas mettre à niveau vers la dernière version 27.1.

Changements notables dans le code et la documentation

Changes 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, and BINANAs.

  • ● Bitcoin Core #29325 commence à stocker les versions de transaction comme des entiers non signés. Depuis la version originale de Bitcoin 0.1, elles étaient stockées comme des entiers signés. Le soft fork BIP68 a commencé à les traiter comme des entiers non signés, mais au moins une réimplémentation de Bitcoin a échoué à reproduire ce comportement, conduisant à un possible échec de consensus (voir le Bulletin #286). En stockant et utilisant toujours les versions de transaction comme des entiers non signés, on espère que toute future implémentation de Bitcoin basée sur la lecture du code de Bitcoin Core utilisera le type correct.

  • ● Eclair #2867 définit un nouveau type de EncodedNodeId à assigner pour les portefeuilles mobiles dans un chemin aveuglé. Cela permet à un fournisseur de portefeuille d’être notifié que le nœud suivant est un dispositif mobile, lui permettant de prendre en compte les conditions spécifiques aux mobiles.

  • ● LND #8730 introduit une commande RPC lncli wallet estimatefee qui reçoit une cible de confirmation en entrée et retourne une estimation de frais pour les transactions on-chain en sat/kw (satoshis par unité de kilo-poids) et sat/vbyte.

  • ● LDK #3098 met à jour le Rapid Gossip Sync (RGS) de LDK vers la v2, qui étend la v1 en ajoutant des champs supplémentaires dans la structure sérialisée. Ces nouveaux champs incluent un octet indiquant le nombre de fonctionnalités de nœud par défaut, un tableau de fonctionnalités de nœud, et des informations supplémentaires de fonctionnalité ou d’adresse de socket suivant chaque clé publique de nœud. Cette mise à jour est distincte de la proposition de mise à jour de gossip BOLT7 également référencée comme gossip v2.

  • ● LDK #3078 ajoute le support pour le paiement asynchrone des factures BOLT12 en générant un événement InvoiceReceived à la réception si l’option de configuration manually_handle_bolt12_invoices est définie. Une nouvelle commande send_payment_for_bolt12_invoice est exposée sur ChannelManager pour payer la facture. Cela peut permettre au code d’évaluer une facture avant de décider de la payer ou de la rejeter.

  • ● LDK #3082 introduit le support de la facture statique BOLT12 (demande de paiement réutilisable) en ajoutant une interface de codage et d’analyse, et des méthodes de construction pour créer une facture statique BOLT12 en réponse à une InvoiceRequest d’une offre.

  • ● LDK #3103 commence à utiliser un évaluateur de performance dans les benchmarks basé sur des sondages fréquents de chemins de paiement réels. L’espoir est que cela résulte en des benchmarks plus réalistes.

  • ● LDK #3037 commence à fermer de force les canaux si leur taux de frais est obsolète et trop bas. LDK suit continuellement le taux de frais acceptable le plus bas que son estimateur a retourné dans la journée précédente. À chaque bloc, LDK fermera tout canal qui paie un taux de frais inférieur au minimum de la veille. L’objectif est “de s’assurer que les taux de frais des canaux sont toujours suffisants pour faire confirmer notre transaction d’engagement on-chain si nous devons fermer de force”.