Le bulletin de cette semaine résume une idée d’utilisation du cluster mempool pour détecter les augmentations du taux de frais des modèles de blocs et partage une mise à jour sur les résultats de simulation de la mitigation du brouillage de canaux. Sont également incluses nos sections régulières résumant les récentes discussions sur la modification des règles de consensus de Bitcoin, annonçant des mises à jour et des versions candidates, et décrivant les changements notables dans les projets d’infrastructure Bitcoin populaires.

Nouvelles

• ● Détection des augmentations du taux de frais des modèles de blocs en utilisant le cluster mempool : Abubakar Sadiq Ismail a récemment publié sur Delving Bitcoin à propos de la possibilité de suivre l’augmentation potentielle des frais à partir de chaque mise à jour du mempool pour fournir un nouveau modèle de bloc aux mineurs uniquement lorsque l’amélioration du taux de frais le justifie. Cette approche réduirait le nombre de constructions de modèles de blocs redondantes, qui peuvent retarder le traitement et la transmission des transactions aux pairs. La proposition tire parti du mempool en cluster pour évaluer si une amélioration du taux de frais est disponible sans reconstruire le modèle de bloc.

  Lorsqu’une nouvelle transaction entre dans le mempool, elle se connecte à zéro ou plusieurs clusters existants déclenchant la re-linéarisation (voir le Bulletin #312 pour plus d’informations sur la linéarisation) des clusters affectés pour produire des diagrammes de taux de frais avant (pré-mise à jour) et après (post-mise à jour) la mise à jour. Le diagramme ancien identifie les blocs potentiels à évincer du modèle de bloc, tandis que le nouveau diagramme identifie les blocs à haut taux de frais pour une addition potentielle. Le système suit ensuite un processus en 4 étapes pour simuler l’impact :

  1. Éviction : Retirer les blocs correspondants d’une copie du modèle, en mettant à jour les frais modifiés et les tailles.

  2. Fusion Naïve : Ajouter de manière gourmande les blocs candidats tout en respectant les limites de poids du bloc pour estimer les gains de frais potentiels (ΔF).

  3. Fusion Itérative : Si l’estimation naïve est non concluante, utiliser une simulation plus détaillée pour affiner ΔF.

  4. Décision : Comparer ΔF à un seuil ; si cela dépasse le seuil, reconstruire le modèle de bloc et l’envoyer aux mineurs. Sinon, passer pour éviter des calculs inutiles.

  La proposition actuelle est encore en phase de discussion, sans prototype disponible.

• ● Résultats de simulation de la mitigation du brouillage de canaux et mises à jour : Carla Kirk-Cohen, en collaboration avec Clara Shikhelman et elnosh, a publié sur Delving Bitcoin à propos de leurs résultats de simulation et des mises à jour avec l’algorithme de réputation pour leur proposition de mitigation du brouillage de canaux. Quelques changements notables sont que la réputation est suivie pour les canaux sortants, et les ressources sont limitées sur les canaux entrants. Bitcoin Optech a précédemment couvert les attaques de brouillage de canaux lightning et un précédent post Delving Bitcoin de Carla. Lisez ces posts pour obtenir une compréhension de base du brouillage de canaux lightning.

  Dans cette dernière mise à jour, ils ont utilisé leur simulateur pour exécuter à la fois les attaques de ressources et les attaques de saturation. Ils ont trouvé que, avec les nouvelles mises à jour, la protection contre les attaques de ressources reste intacte, et avec les attaques par saturation, les nœuds attaquants seront rapidement coupés lorsqu’ils se comportent mal. Il est à noter que si un attaquant construit une réputation puis cible une chaîne de nœuds, seul le dernier nœud est compensé. Mais il y a un coût significatif pour un attaquant à cibler plusieurs nœuds.

  La conclusion de l’article est que la mitigation des attaques par brouillage de canal a atteint un point où elle est suffisamment efficace et encourage les lecteurs à essayer leur simulateur pour tester les attaques.

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.

• ● Lancement du portefeuille BULL : Le portefeuille mobile open source BULL est construit sur BDK et prend en charge les descriptors, l’étiquetage, et la sélection de pièces, Lightning, payjoin, Liquid, les portefeuilles matériels, et les portefeuilles en lecture seule, parmi d’autres fonctionnalités.

• ● Sortie de Sparrow 2.3.0 : Sparrow 2.3.0 ajoute le support pour l’envoi à des adresses de paiement silencieux et les instructions de paiement Bitcoin lisibles par l’homme BIP353, parmi d’autres fonctionnalités et corrections de bugs.

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.

• ● Core Lightning 25.09.1 est une version de maintenance pour la version majeure actuelle de ce nœud LN populaire qui inclut plusieurs corrections de bugs.

• ● Bitcoin Core 28.3 est une version de maintenance pour la série de versions précédente de l’implémentation de nœud complet prédominante. Elle contient plusieurs corrections de bugs, et inclut également les nouveaux paramètres par défaut pour blockmintxfee, incrementalrelayfee, et minrelaytxfee.

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, Serveur BTCPay, BDK, Propositions d’Amélioration de Bitcoin (BIPs), Lightning BOLTs, Lightning BLIPs, Inquisition Bitcoin, et BINANAs.

• ● Bitcoin Core #33157 optimise l’utilisation de la mémoire dans le mempool en cluster en introduisant un type SingletonClusterImpl pour les clusters à transaction unique et en compactant plusieurs internes de TxGraph. Cette PR ajoute également une fonction GetMainMemoryUsage() pour estimer l’utilisation de la mémoire de TxGraph.

• ● Bitcoin Core #29675 introduit le support pour recevoir et dépenser les sorties taproot contrôlées par l’agrégat MuSig2 pour les clés sur les portefeuilles avec des descripteurs musig(0) importés descriptors. Voir le Bulletin #366 pour les travaux préparatoires antérieurs.

• ● Bitcoin Core #33517 et Bitcoin Core #33518 réduisent la consommation CPU du logging multiprocessus en ajoutant des niveaux et catégories de logs, ce qui évite la sérialisation des messages de log de communication inter-processus (IPC) écartés. L’auteur a découvert qu’avant ce PR, le logging représentait 50% du temps CPU de son application cliente Stratum v2 et 10% des processus du nœud Bitcoin. Cela a maintenant chuté à près de zéro pour cent. Voir les Bulletins #323 et #369 pour un contexte supplémentaire.

• ● Eclair #2792 ajoute une nouvelle stratégie de division MPP, max-expected-amount, qui alloue des parties à travers les routes en prenant en compte la capacité de chaque route et la probabilité de succès. Une nouvelle option de configuration mpp.splitting-strategy est ajoutée avec trois options : max-expected-amount, full-capacity, qui considère uniquement la capacité d’une route, et randomize (par défaut), qui rend aléatoire la division. Les deux dernières sont déjà accessibles via la config booléenne randomize-route-selection. Ce PR ajoute l’application des limites maximales HTLC sur les canaux distants.

• ● LDK #4122 permet de mettre en file d’attente une demande de splice tandis que le pair est hors ligne, en commençant la négociation lors de la reconnexion. Pour les splices zero-conf, LDK envoie maintenant un message splice_locked au pair immédiatement après l’échange des tx_signatures. LDK mettra également en file d’attente un splice pendant un splice concurrent et tentera de le réaliser dès que l’autre se verrouille.

• ● LND #9868 définit un type OnionMessage et ajoute deux nouveaux points de terminaison RPC : SendOnionMessage, qui envoie un message onion à un pair spécifique, et SubscribeOnionMessages, qui s’abonne à un flux de messages onion entrants. Ce sont les premières étapes nécessaires pour supporter les BOLT12 offers.

• ● LND #10273 corrige un problème où LND se plantait lorsque le sweeper hérité, utxonursery, tentait de balayer un HTLC avec un locktime (indice de hauteur) de 0. Maintenant, LND balaye avec succès ces HTLC en dérivant l’indice de hauteur de la hauteur de fermeture du canal.