Le bulletin de cette semaine annonce la divulgation responsable d’une vulnérabilité qui permettait à un pair distant de faire planter des nœuds Core Lightning et renvoie vers des transcriptions d’une récente réunion des développeurs de Bitcoin Core. Sont également incluses nos sections régulières annonçant de nouvelles versions et versions candidates et décrivant des changements notables dans des logiciels populaires de l’infrastructure Bitcoin.

Nouvelles

• ● Divulgation d’un DoS par assertion dans Core Lightning : Chandra Pratap a publié sur Delving Bitcoin la divulgation d’une vulnérabilité de déni de service découverte lors d’un stage Summer of Bitcoin
  1. La vulnérabilité affectait les nœuds Core Lightning qui acceptent des canaux entrants.

  Lors de la poignée de main d’ouverture de canal, un pair distant envoie un message contenant le txid de la transaction de financement proposée. Core Lightning effectuait une vérification par assertion exigeant un txid non nul. Lorsqu’un pair envoyait à la place un txid entièrement nul, l’assertion échouait et faisait planter le nœud. Comme n’importe quel pair peut initier une poignée de main d’ouverture de canal et envoyer le message malveillant, cela permettait à un attaquant distant de faire planter de manière fiable tout nœud vulnérable qui acceptait des canaux entrants.

  La vulnérabilité a été divulguée de manière responsable et découverte grâce au fuzzing. Au moment du rapport, Rusty Russell travaillait indépendamment sur un bogue de plantage distinct et son correctif a également résolu incidemment cette vulnérabilité. La vulnérabilité a été corrigée dans Core Lightning 26.04.

• ● Transcriptions de la réunion des développeurs de Bitcoin Core : de nombreux développeurs de Bitcoin Core se sont rencontrés en personne en mai, et les transcriptions de la réunion ont été publiées. Les sujets comprenaient SwiftSync, le mempool post-cluster, une refonte d’Erlay, le relay de paquets, les silent payments, le TCP hole punching (voir le Bulletin #406), la diffusion privée, une bibliothèque cryptographique moderne et les tests par mutation, entre autres.

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.

• ● Eclair v0.14.0 est la dernière version de cette implémentation populaire de nœud LN. Elle inclut les versions finales du splicing, des canaux taproot simples et des engagements sans frais, supprime la prise en charge des canaux non-anchor output, et ajoute un score de pairs expérimental pour l’optimisation de la liquidité et du routage.

• ● Core Lightning 26.06rc2 est une version candidate pour la prochaine version majeure de ce nœud LN populaire qui inclut de nouvelles RPC graceful, sendamount et xkeysend, commence le cycle de dépréciation de pay en faveur de xpay, et ajoute la prise en charge RPC de preuve du payeur pour BOLT12.

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 #33966 remanie la façon dont il gère les options de modèle de bloc de minage pour l’interface IPC de minage (voir les Bulletins #310 et #323). Auparavant, les options de minage au démarrage telles que blockmaxweight, blockreservedweight et blockmintxfee étaient gérées séparément des options d’exécution transmises par les clients de minage IPC. Désormais, ces options sont analysées dans un objet partagé BlockCreateOptions et fusionnées lors de la création ou de la mise à jour des modèles de bloc. Les combinaisons invalides, comme un poids de bloc réservé qui dépasse le poids maximal du bloc, sont désormais rejetées au lieu d’être silencieusement ajustées à une valeur de plage valide.

• ● Bitcoin Core #34917 cesse de renvoyer le champ déprécié bip125-replaceable dans les RPC de transactions du portefeuille listtransactions, listsinceblock et gettransaction, bien que les utilisateurs puissent toujours demander le champ avec l’option -deprecatedrpc=bip125. La PR déprécie également l’option de démarrage -walletrbf, qui émet désormais un avertissement et dont la suppression est prévue dans la prochaine version. Voir le Bulletin #403 pour la suppression précédente de champs liés au RBF.

• ● Bitcoin Core #35017 met à jour le processus de soumission de transactions en paquet afin d’empêcher que des transactions ultérieures restent dans le mempool après un échec inattendu de validation. Lors de la soumission d’un paquet, les transactions sont traitées séquentiellement, permettant aux transactions ultérieures de dépenser des transactions antérieures déjà ajoutées au mempool. Auparavant, si une transaction échouait à une vérification tardive de validation (comme une vérification de script de consensus), Bitcoin Core ne supprimait que cette transaction. Désormais, il supprime aussi toutes les transactions suivantes du paquet, empêchant que des enfants restent dans le mempool après la suppression d’un parent.

• ● BIPs #1944 ajoute BIP449, une proposition préliminaire de soft fork pour OP_TWEAKADD, un opcode tapscript permettant de calculer une clé publique x-only modifiée (voir le Bulletin #370). Étant données une clé publique x-only de 32 octets et un tweak scalaire de 32 octets, l’opcode empile la clé x-only pour P + tG. Cela permettrait aux scripts de vérifier directement des relations de modification de clé, rendant possibles des constructions telles que les scripts de révélation de tweak, la preuve de l’ordre de signature et les protocoles de délégation de signature.

• ● BIPs #2108 ajoute BIP450, Formosa, une spécification préliminaire pour encoder l’entropie de portefeuille compatible BIP39 sous forme de phrases mnémoniques de type histoire. Au lieu d’utiliser des mots BIP39 aléatoires, Formosa utilise des listes de mots définies par thème pour encoder l’entropie, produisant des phrases courtes et structurées. Ces histoires peuvent être redécodées en l’entropie originale et converties en une phrase mnémonique BIP39 standard avant la dérivation de la seed, préservant ainsi la compatibilité avec BIP39.

• ● Eclair #3192 ajoute une prise en charge expérimentale des canaux à engagement sans frais (0FC), conformément à la spécification couverte dans le Bulletin #404. La fonctionnalité est désactivée par défaut et peut être activée avec eclair.features.zero_fee_commitments = optional.

• ● LDK #4584 ajoute des maps payment_metadata aux contextes de message aveuglé et de chemin de paiement de BOLT12. Cela ajoute l’infrastructure nécessaire pour transporter des métadonnées du côté du destinataire à travers des chemins aveuglés et les récupérer lorsque le paiement est reçu, de manière similaire au payment_metadata de BOLT11. La construction d’offres avec métadonnées n’est pas encore prise en charge. Les métadonnées sont stockées sous forme de map de clés numériques vers des tableaux d’octets, permettant d’attacher plusieurs éléments de données indépendants au même paiement.

• ● LDK #4628 commence à chiffrer payment_metadata de BOLT11 lors de la création de paiements entrants, en s’appuyant sur l’engagement de métadonnées couvert dans le Bulletin #405. Après vérification du paiement, LDK déchiffre les métadonnées, permettant aux applications d’accéder aux métadonnées de facture sans les exposer au payeur ni devoir implémenter elles-mêmes le chiffrement.

• ● LND #10552 ajoute une synchronisation initiale rapide pour les nœuds LND adossés à Neutrino en leur permettant d’importer des en-têtes de blocs Bitcoin et des filtres compacts préconstruits depuis des fichiers locaux ou des sources HTTP(S) avant de reprendre la synchronisation P2P normale. Les nouvelles options neutrino.blockheaderssource et neutrino.filterheaderssource doivent être configurées ensemble. Les en-têtes importés sont validés localement, puis Neutrino récupère auprès des pairs du réseau tous les en-têtes postérieurs à la pointe importée.

• ● LND #10820 empêche LND de sélectionner implicitement des canaux taproot simples lors de l’ouverture de canaux publics, car les annonces de canal taproot ne sont pas encore prises en charge. Auparavant, si les deux pairs annonçaient la prise en charge de ce type de canal, LND pouvait le sélectionner puis rejeter l’ouverture. Désormais, les canaux taproot simples doivent être demandés explicitement, tandis que la négociation implicite peut toujours sélectionner les types de canaux hérités, static remote key ou anchor. La PR met également à jour lncli openchannel --channel_type=taproot pour sélectionner le type de canal taproot simple de production.