Le bulletin de cette semaine résume une discussion sur le système de réajustement dynamique du taux de frais de LND mis à jour. Sont également incluses nos sections régulières décrivant les changements récents apportés aux services et aux logiciels clients, annonçant des mises à jour et des versions candidates, et résumant les fusions récentes dans les logiciels d’infrastructure Bitcoin populaires.

Nouvelles

• ● Discussion sur le système de réajustement dynamique du taux de frais de LND : Matt Morehouse a posté sur Delving Bitcoin une description du système sweeper récemment réécrit de LND, qui détermine les taux de frais à utiliser pour les transactions onchain (y compris les augmentations de frais RBF). Il commence par une brève description des aspects critiques de la gestion des frais pour un nœud LN, ainsi que le désir naturel d’éviter de payer trop cher. Il décrit ensuite les deux stratégies générales utilisées par LND :

  • Interroger des estimateurs de taux de frais externes, tels qu’un nœud Bitcoin Core local ou un tiers. Cela est principalement utilisé pour choisir les taux de frais initiaux et pour augmenter les frais des transactions non urgentes.

  • Augmentation exponentielle des frais, utilisée lorsqu’une échéance approche pour s’assurer que les problèmes avec la mempool d’un nœud ou son estimation de frais n’empêchent pas une confirmation en temps voulu. Par exemple, Eclair utilise l’augmentation exponentielle des frais lorsque les échéances sont dans les six blocs.

  Morehouse décrit ensuite comment ces deux stratégies sont combinées dans le nouveau système sweeper de LND : “Les réclamations HTLC avec des échéances correspondantes [sont agrégées] dans une seule transaction groupée. Le budget pour la transaction groupée est calculé comme la somme des budgets pour les HTLC individuels dans la transaction. En fonction du budget de la transaction et de l’échéance, une fonction de frais est calculée qui détermine combien du budget est dépensé à mesure que l’échéance approche. Par défaut, une fonction de frais linéaire est utilisée, qui commence à un faible taux de frais (déterminé par le taux de frais minimum de relais ou un estimateur externe) et se termine avec le budget total alloué aux frais lorsque l’échéance est à un bloc.”

  Il décrit en outre comment la nouvelle logique aide à protéger contre les attaques de cycle de remplacement, concluant : “avec les paramètres par défaut de LND, un attaquant doit généralement dépenser au moins 20 fois la valeur du HTLC pour mener à bien une attaque de cycle de remplacement.” Il ajoute que le nouveau système améliore également la défense de LND contre les attaques d’épinglage.

  Il conclut avec un résumé rempli de liens de plusieurs “corrections de bugs et vulnérabilités spécifiques à LND” réalisées grâce à la logique améliorée. Abubakar Sadiq Ismail a répondu avec quelques suggestions sur comment toutes les implémentations LN (en plus d’autres logiciels) peuvent utiliser plus efficacement l’estimation de frais de Bitcoin Core. Plusieurs autres développeurs ont également commenté, ajoutant à la fois des nuances à la description et des éloges pour la nouvelle approche.

Changements dans les services et logiciels clients

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

• ● Wally 1.4.0 publié : La libwally-core version 1.4.0 ajoute le support de taproot, le support pour la dérivation des clés RSA BIP85, ainsi que des fonctionnalités supplémentaires pour les PSBTs et les descripteurs.

• ● Générateur de configuration Bitcoin Core annoncé : Le projet Bitcoin Core Config Generator est une interface de terminal pour créer des fichiers de configuration bitcoin.conf pour Bitcoin Core.

• ● Un conteneur d’environnement de développement regtest : Le dépôt regtest-in-a-pod fournit un conteneur Podman configuré avec Bitcoin Core, Electrum et Esplora, comme décrit dans le billet de blog Using Podman Containers for Regtest Bitcoin Development.

• ● Outil de visualisation de transactions Explora : Explora est un explorateur basé sur le web pour visualiser et naviguer entre les entrées et sorties de transactions.

• ● Hashpool v0.1 tagué : Hashpool est un pool de minage basé sur l’implémentation de référence Stratum v2 où les parts de minage sont représentées comme des jetons ecash (voir le Podcast #337).

• ● DMND lance le minage en pool : DMND lance le minage en pool Stratum v2, en s’appuyant sur leur précédente annonce de minage solo.

• ● Krux ajoute taproot et miniscript : Krux ajoute le support de miniscript et taproot, en exploitant la bibliothèque embit.

• ● Élément sécurisé à source ouverte annoncé : Le TROPIC01 est un élément sécurisé construit sur RISC-V avec une architecture ouverte pour l’auditabilité.

• ● Nunchuk lance le Group Wallet : Group Wallet prend en charge la multisignature, taproot, le contrôle des pièces, Musig2, et la communication sécurisée entre les participants en réutilisant les descripteurs de sortie dans le fichier BIP129 de Bitcoin Secure Multisig Setup (BSMS).

• ● Protocole FROSTR annoncé : FROSTR utilise le schéma de signature threshold signature pour réaliser la signature k-de-n et la gestion des clés pour nostr.

• ● Bark lancé sur signet : L’implémentation Bark de Ark est maintenant disponible sur signet avec un faucet et un magasin de démonstration pour les tests.

• ● Portefeuille Bitcoin Cove annoncé : Cove Wallet est un portefeuille mobile Bitcoin open source basé sur BDK qui prend en charge des technologies comme les PSBTs, les labels, les dispositifs de signature matérielle, et plus encore.

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.

• ● Bitcoin Core 29.0rc2 est une version candidate pour la prochaine version majeure du nœud complet prédominant du réseau.

Changements notables dans le code et la documentation

Changements notables récents 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 #31649 supprime toute la logique de point de contrôle, qui n’est plus nécessaire suite à l’étape de présynchronisation des en-têtes mise en œuvre il y a des années (voir le Bulletin #216) qui permet à un nœud pendant le Téléchargement Initial de Bloc (IBD) de déterminer si une chaîne d’en-têtes est valide en comparant son travail total prouvé (PoW) à un seuil prédéfini nMinimumChainWork. Seules les chaînes avec un travail prouvé total dépassant cette valeur sont considérées comme valides et stockées, empêchant efficacement les attaques DoS de mémoire par des en-têtes de faible travail. Cela élimine le besoin de points de contrôle, qui étaient souvent vus comme un élément centralisé.

• ● Bitcoin Core #31283 introduit une nouvelle méthode waitNext() à l’interface BlockTemplate, qui ne retournera un nouveau modèle que si le sommet de la chaîne change ou si les frais de la mempool augmentent au-dessus du seuil MAX_MONEY. Auparavant, les mineurs recevaient un nouveau modèle à chaque demande, résultant en une génération de modèle inutile. Ce changement est conforme à la spécification du protocole Stratum V2.

• ● Eclair #3037 améliore la commande listoffers (Voir le Bulletin #345) pour retourner toutes les données pertinentes d’offre, y compris les horodatages createdAt et disabledAt, au lieu de simplement des données Type-Longueur-Valeur (TLV) brutes. De plus, cette PR corrige un bug qui causait le crash du nœud lors de la tentative d’enregistrement de la même offre deux fois.

• ● LND #9546 ajoute un drapeau ip_range à la sous-commande lncli constrainmacaroon (voir le Bulletin #201), permettant aux utilisateurs de restreindre l’accès à une ressource à une plage IP spécifique lors de l’utilisation d’un macaroon (jeton d’authentification). Auparavant, les macaroons ne pouvaient autoriser ou refuser l’accès que sur la base d’adresses IP spécifiques, et non de plages.

• ● LND #9458 introduit des emplacements d’accès restreints pour certains pairs, configurables via le drapeau --num-restricted-slots, pour gérer les permissions d’accès initiales sur le serveur. Les pairs se voient attribuer des niveaux d’accès en fonction de leur historique de canal : ceux avec un canal confirmé reçoivent un accès protégé, ceux avec un canal non confirmé reçoivent un accès temporaire, et tous les autres reçoivent un accès restreint.

• ● BTCPay Server #6581 ajoute le support RBF, permettant l’augmentation des frais pour les transactions qui n’ont pas de descendants, où tous les inputs proviennent du portefeuille du magasin, et qui incluent une des adresses de changement du magasin. Les utilisateurs peuvent maintenant choisir entre CPFP et RBF lorsqu’ils décident d’augmenter les frais d’une transaction. L’augmentation des frais nécessite la version 2.5.22 de NBXplorer ou supérieure.

• ● BDK #1839 ajoute le support pour la détection et la gestion des transactions annulées (double dépense) en introduisant un nouveau champ TxUpdate::evicted_ats, qui met à jour les horodatages last_evicted dans TxGraph. Les transactions sont considérées comme évacuées si leur horodatage last_evicted dépasse leur horodatage last_seen. L’algorithme de canonicalisation (voir le Bulletin #335) est mis à jour pour ignorer les transactions évacuées sauf lorsqu’un descendant canonique existe en raison des règles de transitivité.

• ● BOLTs #1233 met à jour le comportement d’un nœud pour ne jamais échouer un HTLC en amont si le nœud connaît la préimage, assurant que le HTLC peut être correctement réglé. Auparavant, la recommandation était de faire échouer un HTLC en attente en amont s’il manquait un engagement confirmé, même si la préimage était connu. Un bug dans les versions de LND avant 0.18 causait l’échec des HTLCs en amont après un redémarrage sous attaque DoS, malgré la connaissance de la préimage, résultant dans la perte de la valeur du HTLC (voir le Bulletin #344).