Le bulletin de cette semaine décrit une vulnérabilité affectant les anciennes versions de LDK, examine un aspect nouvellement révélé d’une vulnérabilité initialement publiée en 2023, et résume la discussion renouvelée sur les statistiques de reconstruction de blocs compacts. Sont également incluses nos rubriques habituelles avec des questions et réponses populaires de la communauté Bitcoin Stack Exchange, des annonces de nouvelles versions et de versions candidates, ainsi que les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

  • ● Vulnérabilité dans le traitement des réclamations LDK : Matt Morehouse a publié sur Delving Bitcoin pour divulguer une vulnérabilité affectant LDK qu’il a divulguée de manière responsable et qui a été corrigée dans la version 0.1 de LDK. Lorsqu’un canal est fermé unilatéralement avec plusieurs HTLCs en attente, LDK tentera de résoudre autant de HTLCs que possible dans la même transaction pour économiser sur les frais de transaction. Cependant, si la contrepartie du canal parvient à confirmer l’un des HTLCs groupés en premier, cela entrera en conflit avec la transaction groupée et la rendra invalide. Dans ce cas, LDK créerait correctement une transaction groupée mise à jour avec le conflit supprimé. Malheureusement, si la transaction de la contrepartie entre en conflit avec plusieurs lots séparés, LDK mettrait à jour incorrectement seulement le premier lot. Les lots restants ne pourraient pas être confirmés.

    Les nœuds doivent résoudre leurs HTLCs avant une date limite, sinon la contrepartie peut récupérer ses fonds. Un timelock empêche la contrepartie de dépenser les HTLCs avant leurs échéances individuelles. La plupart des anciennes versions de LDK plaçaient ces HTLCs dans un lot séparé qu’elles s’assuraient de confirmer avant que la contrepartie puisse confirmer une transaction en conflit, garantissant qu’aucun fonds ne pouvait être volé. Pour les HTLCs qui ne permettaient pas le vol de fonds, mais que la contrepartie pouvait résoudre immédiatement, il y avait un risque que la contrepartie puisse causer le blocage des fonds. Morehouse écrit que cela peut être corrigé en “passant à la version 0.1 de LDK et en rejouant la séquence de transactions d’engagement et de HTLC qui ont conduit au blocage.”

    Cependant, le candidat à la version LDK 0.1-beta a changé sa logique (voir le Bulletin #335) et a commencé à regrouper tous les types de HTLCs ensemble, ce qui pourrait permettre à un attaquant de créer un conflit avec un HTLC à timelock. Si la résolution de ce HTLC restait bloquée après l’expiration du timelock, un vol était possible. Passer à la version de sortie de LDK 0.1 corrige également cette forme de vulnérabilité.

    Le post de Morehouse fournit des détails supplémentaires et discute des moyens possibles de prévenir les futures vulnérabilités découlant de la même cause racine.

  • ● Attaques de remplacement cyclique avec exploitation des mineurs : Antoine Riard a publié sur la liste de diffusion Bitcoin-Dev pour divulguer une vulnérabilité supplémentaire possible avec l’attaque de remplacement cyclique qu’il avait initialement rendue publique et divulgué en 2023 (voir le Bulletin #274). En bref :

    1. Bob diffuse une transaction payant Mallory (et possiblement d’autres personnes).

    2. Mallory bloque la transaction de Bob.

    3. Bob ne réalise pas qu’il a été bloqué et augmente les frais (en utilisant soit RBF soit CPFP).

    4. Comme la transaction originale de Bob a été bloquée, son augmentation de frais ne se propage pas. Cependant, Mallory la reçoit d’une manière ou d’une autre. Les étapes 3 et 4 peuvent se répéter plusieurs fois pour augmenter considérablement les frais de Bob.

    5. Mallory mine l’augmentation de frais la plus élevée de Bob, que personne d’autre n’essaie de miner parce qu’elle ne s’est pas propagée. Cela permet à Mallory de gagner plus de frais que les autres mineurs.

    6. Mallory peut maintenant utiliser le remplacement cyclique pour déplacer son blocage de transaction vers une autre transaction et répéter l’attaque (éventuellement avec une victime différente) sans allouer de fonds supplémentaires, rendant l’attaque économiquement efficace.

    Nous ne considérons pas la vulnérabilité comme un risque significatif. Exploiter la vulnérabilité nécessite des circonstances spécifiques qui pourraient être rares et peuvent entraîner une perte d’argent pour l’attaquant s’ils évaluent mal les conditions du réseau. Si un attaquant exploitait régulièrement la vulnérabilité, nous croyons que leur comportement serait détecté par les membres de la communauté qui construisent et utilisent des outils de surveillance de blocs.

  • ● Statistiques mises à jour sur la reconstruction de blocs compacts : faisant suite à un fil de discussion précédent (voir le Bulletin #315), le développeur 0xB10C a publié sur Delving Bitcoin des statistiques mises à jour sur la fréquence à laquelle ses nœuds Bitcoin Core devaient demander des transactions supplémentaires pour effectuer la reconstruction de blocs compacts. Lorsqu’un nœud reçoit un bloc compact, il doit demander toute transaction dans ce bloc qu’il n’a pas déjà dans son mempool (ou dans son extrapool, qui est une réserve spéciale visant à aider à la reconstruction de blocs compacts). Cela ralentit considérablement la vitesse de propagation des blocs et contribue à la centralisation des mineurs.

    0xB10C a constaté que la fréquence des demandes augmentait significativement à mesure que la taille du mempool augmentait. Plusieurs développeurs ont discuté des causes possibles, avec des données initiales indiquant que les transactions manquantes étaient des orphelines— des transactions enfants de parents inconnus, que Bitcoin Core ne stocke que brièvement au cas où leurs parents arriveraient dans un court délai. Un meilleur suivi et une demande des parents de transactions orphelines, récemment intégrés à Bitcoin Core (voir le Bulletin #338), pourraient aider à améliorer cette situation.

    Les développeurs ont également discuté d’autres solutions possibles. Les nœuds ne peuvent pas raisonnablement conserver les transactions orphelines pendant longtemps car un attaquant peut les créer gratuitement—mais il pourrait être possible de persister un plus grand nombre d’entre elles et d’autres transactions évincées plus longtemps dans l’extrapool. La discussion était non concluante au moment de la rédaction.

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 plus votées postées depuis notre dernière mise à jour.

Mises à jour et versions candidates

Nouvelles mises à jour et versions candidates à la sortie pour des projets d’infrastructure Bitcoin populaires. Veuillez envisager de passer aux nouvelles versions ou d’aider à tester les versions candidates.

  • ● LDK v0.1.1 est une version de sécurité de cette bibliothèque populaire pour la création d’applications compatibles LN. Un attaquant prêt à sacrifier au moins 1% des fonds du canal pourrait tromper la victime en la poussant à fermer d’autres canaux non liés, ce qui pourrait amener la victime à dépenser inutilement de l’argent en frais de transaction. Matt Morehouse, qui a découvert la vulnérabilité, a publié à ce sujet sur Delving Bitcoin; Optech fournira un résumé plus détaillé dans le bulletin de la semaine prochaine. La version inclut également des mises à jour de l’API et des corrections de bugs.

Changements de code et de documentation notables

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

  • ● Bitcoin Core #31376 étend une vérification qui empêche les mineurs de créer des modèles de blocs exploitant le bug timewarp pour s’appliquer à tous les réseaux, pas seulement testnet4. Ce changement est en préparation pour un éventuel futur soft fork qui corrigerait définitivement le bug timewarp.

  • ● Bitcoin Core #31583 met à jour les commandes RPC getmininginfo, getblock, getblockheader, getblockchaininfo et getchainstates pour désormais retourner un champ nBits (la représentation compacte de la cible de difficulté du bloc) et un champ target. De plus, getmininginfo ajoute un objet next qui spécifie la hauteur, nBits, la difficulté et la cible pour le prochain bloc. Pour dériver et obtenir la cible, ce PR introduit le DeriveTarget() et les fonctions d’aide GetTarget(). Ces changements sont utiles pour la mise en œuvre du Stratum V2.

  • ● Bitcoin Core #31590 refactorise la méthode GetPrivKey() pour vérifier les pubkeys pour les deux valeurs de bit de parité lors de la récupération des clés privées pour un x-only pubkey dans un descriptor. Auparavant, si le pubkey stocké n’avait pas le bit de parité correct, la clé privée ne pouvait pas être récupérée et les transactions ne pouvaient pas être signées.

  • ● Eclair #2982 introduit le paramètre de configuration lock-utxos-during-funding, permettant aux vendeurs de publicité de liquidité d’atténuer une attaque de griefing de liquidité qui pourrait empêcher les utilisateurs honnêtes d’utiliser leurs UTXOs pendant de longues périodes. Le paramètre par défaut est vrai, signifiant que les UTXOs sont verrouillés pendant le processus de financement et sont vulnérables à l’abus. Si réglé sur faux, le verrouillage des UTXO est désactivé et l’attaque peut être complètement prévenue, mais cela peut affecter négativement les pairs honnêtes. Cette PR ajoute également un mécanisme de délai configurable qui interrompt automatiquement les canaux entrants si un pair devient non réactif.

  • ● BDK #1614 ajoute le support pour l’utilisation des filtres de blocs compacts tel que spécifié dans BIP158 pour télécharger les transactions confirmées. Cela est réalisé en ajoutant un module BIP158 au paquet bdk_bitcoind_rpc, ainsi qu’un nouveau type FilterIter qui peut être utilisé pour récupérer les blocs contenant des transactions pertinentes à une liste de script pubkeys.

  • ● BOLTs #1110 fusionne la spécification pour le protocole de stockage par pair, qui permet aux nœuds de stocker des blobs cryptés jusqu’à 64kB pour les pairs qui les demandent, et de facturer pour ce service. Cela a déjà été implémenté dans Core Lightning (voir le bulletin #238) et Eclair (voir le bulletin #335).