Le bulletin de cette semaine annonce une correction de vulnérabilité affectant LDK, résume la discussion sur le gossip à connaissance nulle pour les annonces de canaux LN, décrit la découverte de recherches antérieures qui peuvent être appliquées à la recherche de linéarisations de clusters optimales, fournit une mise à jour sur le développement du protocole Erlay pour réduire la bande passante de relais de transactions, examine les compromis entre différents scripts pour l’implémentation d’ancres éphémères LN, relaye une proposition pour émuler un opcode OP_RAND de manière à préserver la vie privée sans nécessiter de changements de consensus, et pointe vers une discussion renouvelée sur l’abaissement du taux de frais minimum pour les transactions.

Nouvelles

• ● Vulnérabilité de fermeture forcée de canal dans LDK : Matt Morehouse a publié sur Delving Bitcoin pour annoncer 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.1 de LDK. Similaire à une autre vulnérabilité récemment divulguée par Morehouse dans LDK (voir le Bulletin #339), une boucle dans le code de LDK se terminait la première fois qu’elle traitait une occurrence inhabituelle, l’empêchant de gérer des occurrences supplémentaires du même problème. Dans ce cas, cela pourrait entraîner l’échec de LDK à régler les HTLCs en attente dans les canaux ouverts, conduisant finalement les contreparties honnêtes à fermer de force les canaux afin qu’elles puissent régler les HTLCs onchain.

  Cela ne pourrait probablement pas conduire à un vol direct, mais cela pourrait entraîner le paiement par la victime des frais pour les canaux fermés, des frais pour ouvrir de nouveaux canaux, et réduire la capacité de la victime à gagner des frais de transfert.

  L’excellent post de Morehouse entre dans les détails supplémentaires et suggère comment éviter les futurs bugs provenant de la même cause sous-jacente.

• ● Gossip à connaissance nulle pour les annonces de canaux LN : Johan Halseth a publié sur Delving Bitcoin avec une extension au protocole proposé d’annonce de canal 1.75 topic channel announcements qui permettrait à d’autres nœuds de vérifier qu’un canal est soutenu par une transaction de financement, prévenant de multiples attaques DoS bon marché, mais sans révéler quelle UTXO est la transaction de financement, améliorant ainsi la confidentialité. L’extension de Halseth s’appuie sur ses recherches précédentes (voir le Bulletin #321) qui utilisent utreexo et un système de preuve à connaissance nulle (ZK). Elle serait appliquée aux canaux simple taproot basés sur MuSig2.

  La discussion s’est concentrée sur les compromis entre l’idée de Halseth, la continuation de l’utilisation de gossip non privé, et les méthodes alternatives pour générer la preuve ZK. Les préoccupations incluaient l’assurance que tous les nœuds LN peuvent rapidement vérifier les preuves et la complexité du système de preuve et de vérification puisque tous les nœuds LN devront l’implémenter.

  La discussion était en cours au moment de la rédaction de ce résumé.

• ● Découverte de recherches antérieures pour trouver une linéarisation optimale des clusters : Stefan Richter a publié sur Delving Bitcoin à propos d’un article de recherche de 1989, il a découvert qu’il existe un algorithme éprouvé qui peut être utilisé pour trouver efficacement le sous-ensemble de transactions avec le taux de frais le plus élevé qui sera topologiquement valide si le sous-ensemble est inclus dans un bloc. Il a également trouvé une implémentation en C++ de plusieurs algorithmes pour des problèmes similaires qui “sont censés être encore plus rapides en pratique”.

  Les travaux antérieurs sur le regroupement du pool de mémoire se sont concentrés sur la facilitation et l’accélération de la comparaison entre différentes linéarisations afin que la meilleure puisse être utilisée. Cela permettrait d’utiliser un algorithme rapide pour linéariser immédiatement un cluster, avec un algorithme plus lent mais plus optimal pouvant fonctionner sur des cycles CPU disponibles. Cependant, si l’algorithme de 1989 pour le problème de fermeture à ratio maximum, ou un autre algorithme pour ce problème, peut fonctionner assez rapidement, il pourrait être utilisé tout le temps. Mais, même s’il était modérément lent, il pourrait encore être utilisé comme l’algorithme qui fonctionne sur des cycles CPU disponibles.

  Pieter Wuille a répondu avec enthousiasme et plusieurs questions de suivi. Il a également décrit un nouvel algorithme de linéarisation de cluster que le groupe de travail sur le pool de mémoire de cluster a développé sur la base d’une discussion lors de la semaine de recherche sur Bitcoin avec Dongning Guo et Aviv Zohar. Il convertit le problème en un qui peut être abordé en utilisant la programmation linéaire et semble être rapide, facile à implémenter et produit une linéarisation optimale—s’il se termine. Cependant, une preuve est nécessaire pour montrer qu’il se terminera (et dans un délai raisonnable).

  Bien que non directement lié à Bitcoin, nous avons trouvé intéressante la description de Richter sur la manière dont il a trouvé l’article de 1989 en utilisant le raisonnement LLM de DeepSeek.

  Au moment de la rédaction, la discussion était en cours et des articles supplémentaires sur le domaine du problème étaient explorés. Richter a écrit : “Il semble que notre problème, ou plutôt, sa solution généralisée qui est appelée source-sink-monotone parametric min-cut a des applications dans quelque chose appelé agrégation de polygones pour la simplification de carte et d’autres sujets en vision par ordinateur.”

• ● Mise à jour sur Erlay : Sergi Delgado a fait plusieurs publications sur Delving Bitcoin concernant son travail au cours de l’année passée sur l’implémentation d’Erlay pour Bitcoin Core. Il commence par un aperçu de la manière dont la diffusion de transactions existante (appelée fanout) fonctionne et comment Erlay propose de changer cela. Il note que du fanout est attendu même dans un réseau où chaque nœud prend en charge Erlay, car “le fanout est plus efficace et considérablement plus rapide que la réconciliation d’ensemble, à condition que le nœud récepteur ne connaisse pas la transaction annoncée.”

  L’utilisation d’un mélange de fanout et de réconciliation nécessite de choisir quand utiliser chaque méthode et avec quels pairs les utiliser, donc ses recherches se sont concentrées sur la prise des choix optimaux :

  • ● Filtrage basé sur la connaissance de la transaction examine si un nœud doit inclure un pair dans ses plans pour diffuser une transaction même s’il sait que ce pair possède déjà la transaction. Par exemple, notre nœud a dix pairs ; trois de ces pairs ont déjà annoncé une transaction vers nous. Si nous voulons choisir aléatoirement trois pairs pour propager davantage cette transaction, devrions-nous sélectionner parmi les dix pairs ou juste parmi les sept pairs qui ne nous ont pas encore annoncé la transaction ? De manière surprenante, les résultats de simulation montrent qu’“il n’y a pas de différence significative entre [les options]”. Delgado explore ce résultat surprenant et conclut que tous les pairs devraient être considérés (c’est-à-dire, aucun filtrage ne devrait être effectué).

  • ● Quand sélectionner les pairs candidats pour le fanout examine quand un nœud devrait choisir quels pairs recevront une transaction de fanout (le reste utilisant la réconciliation Erlay). Deux options sont considérées : peu après qu’un nœud valide une nouvelle transaction et la mette en file d’attente pour la relayer, et quand il est temps pour cette transaction d’être relayée (les nœuds ne relayent pas immédiatement les transactions : ils attendent un petit laps de temps aléatoire pour rendre plus difficile la sonde du réseau topologie et deviner quel nœud est à l’rigine une transaction, ce qui serait mauvais pour la confidentialité). Encore une fois, les résultats de simulation montrent qu’“il n’y a pas de différences significatives”, bien que les “résultats peuvent varier […] dans des réseaux avec un support [Erlay] partiel”.

  • ● Combien de pairs devraient recevoir un fanout examine le taux de fanout. Un taux plus élevé accélère la propagation de la transaction mais réduit les économies de bande passante. Outre le test du taux de fanout, Delgado a également testé l’augmentation du nombre de pairs sortants, car c’est l’un des objectifs de l’adoption d’Erlay. La simulation montre que l’approche Erlay actuelle a réduit la bande passante d’environ 35% en utilisant les limites actuelles de pairs sortants (8 pairs), et 45% en utilisant 12 pairs sortants. Cependant, la latence de la transaction est augmentée d’environ 240%. De nombreux autres compromis sont graphiqués dans le post. En plus des résultats étant utiles pour choisir les paramètres actuels, Delgado note qu’ils seront utiles pour évaluer des algorithmes de fanout alternatifs qui pourraient être capables de faire de meilleurs compromis.

  • ● Définir le taux de fanout en fonction de la manière dont une transaction a été reçue examine si le taux de fanout devrait être ajusté en fonction de si une transaction a été reçue pour la première fois via fanout ou réconciliation. De plus, s’il devrait être ajusté, quel taux ajusté devrait être utilisé ? L’idée est que le fanout est plus rapide et plus efficace lorsqu’une nouvelle transaction commence à être relayée à travers le réseau, mais cela conduit à une bande passante gaspillée après qu’une transaction a déjà atteint la plupart des nœuds. Il n’y a aucun moyen pour un nœud de déterminer directement combien d’autres nœuds ont déjà vu une transaction, mais si le pair qui lui a envoyé une transaction pour la première fois a utilisé le fanout plutôt que d’attendre la prochaine réconciliation programmée, alors il est plus probable que la transaction est dans les premiers stades de la propagation. Ces données peuvent être utilisées pour augmenter modérément le propre taux de fanout du nœud pour cette transaction afin de l’aider à se propager plus rapidement. Delgado a simulé l’idée et a trouvé un ratio de fanout modifié qui diminue le temps de propagation de 18% avec seulement une augmentation de 6,5% de la bande passante par rapport au résultat de contrôle qui utilise le même taux de fanout pour toutes les transactions.

• ● Compromis dans les scripts d’ancrage éphémères de LN : Bastien Teinturier a posté sur Delving Bitcoin pour demander des avis à propos de quel script d’ancre éphémère devrait être utilisé comme l’un des résultats pour les transactions d’engagement LN basées sur TRUC en remplacement des ancres de sortie existantes. Le script utilisé détermine qui peut augmenter les frais CPFP de la transaction d’engagement (et sous quelles conditions ils peuvent le faire). Il a présenté quatre options :

  • ● Utiliser un script pay-to-anchor (P2A) : cela a une taille minimale onchain mais signifie que toute la valeur HTLC élaguée ira probablement aux mineurs (comme c’est le cas actuellement).

  • ● Utiliser une ancre à clé unique pour un seul participant : cela peut permettre à un participant de réclamer une partie de la valeur HTLC élaguée en acceptant volontairement d’attendre quelques dizaines de blocs avant de pouvoir dépenser l’argent qu’ils retirent d’un canal. Quiconque souhaite fermer un canal de force doit de toute façon attendre ce délai. Cependant, aucune des parties du canal ne peut déléguer le paiement des frais à un tiers sans permettre à ce dernier de voler tous leurs fonds du canal. Si vous et votre contrepartie vous disputez pour réclamer la valeur excédentaire, elle ira probablement de toute façon aux mineurs.

  • ● Utiliser une ancre à clé partagée : cela permet également de récupérer la valeur HTLC élaguée excédentaire et autorise la délégation, mais quiconque reçoit la délégation peut vous concurrencer et votre contrepartie pour réclamer la valeur excédentaire. Là encore, en cas de concurrence, toute la valeur excédentaire ira probablement aux mineurs.

  • ● Utiliser une ancre à double clé : cela permet à chaque participant de réclamer la valeur HTLC élaguée excédentaire sans avoir à attendre des blocs supplémentaires avant de pouvoir dépenser. Cependant, cela ne permet pas la délégation. Les deux parties d’un canal peuvent toujours se concurrencer.

  Dans les réponses au post, Gregory Sanders a noté que les différents schémas pourraient être utilisés à différents moments. Par exemple, P2A pourrait être utilisé lorsqu’il n’y avait pas de HTLC élagués, et l’une des ancres à clé pourrait être utilisée à d’autres moments. Si la valeur élaguée était au-dessus du seuil de poussière, cette valeur pourrait être ajoutée à la transaction d’engagement LN au lieu d’une sortie d’ancre. De plus, il a averti que cela pourrait créer “une nouvelle étrangeté [une] contrepartie pourrait être tentée d’augmenter le montant élagué et de le prendre elle-même.” David Harding a développé ce thème dans un post ultérieur.

  Antoine Riard a averti contre l’utilisation de P2A en raison du risque d’encourager le blocage de transaction par les mineurs (voir le Bulletin #339).

  La discussion était en cours au moment de la rédaction.

• ● Émuler OP_RAND : Oleksandr Kurbatov a posté sur Delving Bitcoin à propos d’un protocole interactif qui permet à deux parties de conclure un contrat qui sera payé d’une manière que ni l’une ni l’autre ne peut prévoir, ce qui est fonctionnellement équivalent à aléatoirement. Des travaux antérieurs sur les paiements probabilistes dans Bitcoin ont utilisé des scripts avancés, mais l’approche de Kurbatov utilise des clés publiques spécialement construites. qui permet au gagnant de dépenser les fonds contractés. Cela est plus privé et peut permettre une plus grande flexibilité.

  Optech n’a pas pu analyser entièrement le protocole, mais nous n’avons pas repéré de problèmes évidents. Nous espérons voir une discussion supplémentaire sur l’idée—les paiements probabilistes ont de multiples applications, y compris permettre aux utilisateurs d’envoyer des montants onchain qui seraient autrement non économiques, comme pour les HTLCs élagués.

• ● Discussion sur la réduction du taux minimum de frais de relais de transaction : Greg Tonoski a posté sur la liste de diffusion Bitcoin-Dev concernant la réduction du taux de frais de relais de transaction minimum par défaut, un sujet qui a été discuté à plusieurs reprises (et résumé par Optech) depuis 2018—plus récemment en 2022 (voir le Bulletin #212). À noter, une vulnérabilité récemment divulguée (voir le Bulletin #324) a révélé un problème potentiel qui aurait pu affecter les utilisateurs et les mineurs qui avaient réduit ce paramètre par le passé. Optech fournira des mises à jour s’il y a une discussion significative ultérieure.

Changement de consensus

Une section mensuelle résumant les propositions et discussions sur le changement des règles de consensus de Bitcoin.

• ● Mises à jour de la proposition de soft fork de nettoyage du consensus : Antoine Poinsot a fait plusieurs publications sur le fil Delving Bitcoin concernant le soft fork de nettoyage du consensus suggérant des changements de paramètres :

  • ● Introduire une limite de sigops pour les entrées legacy : dans un fil privé, Poinsot et plusieurs autres contributeurs ont tenté de produire un bloc pour regtest qui prendrait le plus de temps possible à valider en utilisant les problèmes connus dans la validation des transactions legacy (pré-segwit). Après recherche, il a trouvé qu’il pouvait “adapter [le pire bloc] pour qu’il soit valide sous les atténuations initialement proposées en 2019” (voir le Bulletin #36). Cela le conduit à proposer une atténuation différente : limiter le nombre maximum d’opérations de signature (sigops) dans les transactions legacy à 2 500. Chaque exécution de OP_CHECKSIG compte pour un sigop et chaque exécution de OP_CHECKMULTISIG peut compter jusqu’à 20 sigops (selon le nombre de clés publiques utilisées avec elle). Son analyse montre que cela diminuera le temps de validation dans le pire des cas de 97,5%.

    Comme pour tout changement de ce type, il y a un risque de confiscation accidentelle en raison de la nouvelle règle rendant les transactions précédemment signées invalides. Si vous connaissez quelqu’un qui nécessite des transactions legacy avec plus de 2 500 opérations de signature unique ou plus de 2 125 clés pour des opérations multisig¹, veuillez alerter Poinsot ou d’autres développeurs de protocole.

  • ● Augmenter la période de grâce du timewarp à 2 heures : auparavant, la proposition de nettoyage interdisait au premier bloc d’une nouvelle période de difficulté d’avoir un temps d’en-tête de bloc de plus de 600 secondes avant le temps du bloc précédent. Cela signifiait qu’une quantité constante de hashrate ne pouvait pas utiliser la vulnérabilité timewarp pour produire des blocs plus rapidement qu’une fois toutes les 10 minutes.

    Poinsot accepte désormais d’utiliser une période de grâce de 7 200 secondes (2 heures), comme initialement proposé par Sjors Provoost, étant beaucoup moins susceptible de conduire à ce qu’un mineur produise accidentellement un bloc invalide, bien que cela permette à un attaquant très patient contrôlant plus de 50 % du hashrate du réseau d’utiliser l’attaque de timewarp pour réduire la difficulté sur une période de mois même si le hashrate réel reste constant ou augmente. Ce serait une attaque visiblement publique et le réseau aurait des mois pour réagir. Dans son post, Poinsot résume les arguments précédents (voir le Bulletin #335 pour notre résumé beaucoup moins détaillé) et conclut que, “malgré les arguments plutôt faibles en faveur de l’augmentation de la période de grâce, le coût d’une telle mesure [n’interdit] pas d’opter pour la prudence.”

    Dans un fil de discussion dédié à l’extension de la période de grâce, les développeurs Zawy et Pieter Wuille ont discuté comment la période de grâce de 600 secondes, qui semblerait permettre de diminuer lentement la difficulté à sa valeur minimale, était en réalité suffisante pour empêcher plus d’une petite diminution de difficulté. Spécifiquement, ils ont examiné l’impact du bug d’ajustement de difficulté off-by-one de Bitcoin et l’asymétrie de la distribution erlang sur le ciblage précis de la difficulté. Zawy a conclu succinctement, “Ce n’est pas qu’un ajustement pour à la fois Erlang et le ‘trou de 2015’ n’est pas nécessaire, c’est que 600 secondes avant le bloc précédent n’est pas un mensonge de 600 secondes, c’est un mensonge de 1200 secondes parce que nous attendions un horodatage 600 secondes après.”

  • ● Correction de transaction en double : suite à une demande de retour d’information de la part des mineurs (voir le Bulletin #332) concernant les impacts négatifs potentiels des solutions de consensus au problème des transactions en double, Poinsot a sélectionné une solution spécifique à inclure dans la proposition de nettoyage : exiger que la hauteur du bloc précédent soit incluse dans le champ de verrouillage temporel de chaque transaction coinbase. Cette proposition a deux avantages : elle permet d’extraire la hauteur du bloc engagé d’un bloc sans avoir à analyser le Script et elle permet de créer une preuve compacte basée sur SHA256 de la hauteur du bloc (environ 700 octets dans le pire des cas, bien moins que la preuve de 1 Mo dans le pire des cas qui serait nécessaire maintenant sans un système de preuve avancé).

    Ce changement n’affectera pas les utilisateurs réguliers mais nécessitera éventuellement que les mineurs mettent à jour le logiciel qu’ils utilisent pour générer des transactions coinbase. Si des mineurs ont des préoccupations concernant cette proposition, veuillez contacter Poinsot ou un autre développeur de protocole.

  Poinsot a également publié une mise à jour de haut niveau sur son travail et l’état actuel de la proposition sur la liste de diffusion Bitcoin-Dev.

• ● Demande pour une conception de covenant soutenant Braidpool : Bob McElrath a posté sur Delving Bitcoin demandant aux développeurs travaillant sur des conceptions de covenant de considérer comment leur proposition préférée, ou une nouvelle proposition, pourrait aider à la création d’une pool de minage décentralisée efficace. Le design prototype actuel pour Braidpool utilise une fédération de signataires, où les signataires reçoivent des parts de signature de seuil basées sur leur contribution de taux de hachage au pool. Cela permet à un mineur majoritaire (ou à une collusion de plusieurs mineurs constituant une majorité) de voler les paiements des mineurs plus petits. McElrath préférerait utiliser une covenant qui assure que chaque mineur peut retirer des fonds du pool proportionnellement à leurs contributions. Il fournit une liste spécifique d’exigences dans le post ; il accueille également une preuve d’impossibilité.

  À l’heure actuelle, il n’y a eu aucune réponse.

• ● Sélection transactionnelle déterministe à partir d’un mempool engagé : un fil de discussion d’avril 2024 a reçu une attention renouvelée le mois passé. Auparavant, Bob McElrath a posté sur le fait d’avoir les mineurs s’engager sur les transactions dans leur mempool et ensuite ne leur permettre d’inclure dans leurs blocs que les transactions qui ont été sélectionnées de manière déterministe à partir des engagements précédents. Il voit deux applications :

  • Globalement pour tous les mineurs : cela éliminerait le “risque et la responsabilité de la sélection des transactions” dans un monde où les mineurs sont souvent de grandes entités corporatives qui doivent se conformer aux lois, régulations, et aux conseils des gestionnaires de risques.

  • Localement pour un seul pool : cela a la plupart des avantages d’un algorithme déterministe global mais ne nécessite aucun changement de consensus pour être mis en œuvre. De plus, cela peut économiser une grande quantité de bande passante entre pairs dans un pool de minage décentralisé tel que Braidpool, car l’algorithme détermine quelles transactions un bloc candidat doit inclure, donc toute part produite à partir de ce bloc n’a pas besoin de fournir explicitement des données de transaction aux pairs du pool.

  Anthony Towns a décrit plusieurs problèmes potentiels avec une option de changement de consensus global : tout changement dans la sélection des transactions nécessiterait un changement de consensus (possiblement un hard fork) et quiconque ayant créé une transaction non standard serait incapable de la faire miner même avec la coopération d’un mineur. Les changements de politique récents au cours des dernières années qui auraient nécessité un changement de consensus incluent : TRUC, les politiques RBF mises à jour, et les ancres éphémères. Towns a lié à un cas bien connu où des millions de dollars en valeur ont été accidentellement bloqués dans un script non standard, qu’un mineur coopératif a pu débloquer.

  Le reste de la discussion s’est concentré sur l’approche locale telle que conçue pour Braidpool. Il n’y a eu aucune objection et une discussion supplémentaire sur un sujet concernant un algorithme d’ajustement de la difficulté (voir l’élément suivant dans cette section) a montré comment cela pourrait être particulièrement utile pour un pool qui crée des blocs à un taux beaucoup plus élevé que Bitcoin, où le déterminisme de la sélection des transactions réduit considérablement la bande passante, la latence et les coûts de validation.

• ● Algorithme d’ajustement de la difficulté rapide pour une blockchain DAG : le développeur Zawy a posté sur Delving Bitcoin à propos d’un algorithme d’ajustement de la difficulté (DAA) pour une blockchain de type graphe acyclique dirigé (DAG). L’algorithme a été conçu pour être utilisé dans le consensus entre pairs de Braidpool (pas dans le consensus global de Bitcoin), cependant la discussion a régulièrement touché à des aspects du consensus global. Dans la blockchain de Bitcoin, chaque bloc s’engage envers un seul parent ; plusieurs blocs enfants peuvent s’engager envers le même parent, mais un seul d’entre eux sera considéré comme valide sur la meilleure blockchain par un nœud. Dans une blockchain DAG, chaque bloc peut s’engager envers un ou plusieurs parents et peut avoir zéro ou plusieurs enfants qui s’engagent envers lui ; la meilleure blockchain DAG peut considérer plusieurs blocs de la même génération comme valides.

  

  Le DAA proposé cible le nombre moyen de parents dans les 100 derniers blocs valides observés. Si le nombre moyen de parents augmente, l’algorithme augmente la difficulté ; s’il y a moins de parents, la difficulté diminue. Viser une moyenne de deux parents offre le consensus le plus rapide, selon Zawy. Contrairement au DAA de Bitcoin, le DAA proposé n’a pas besoin de prendre en compte le temps ; cependant, il nécessite que les pairs ignorent les blocs qui arrivent bien après les autres blocs de la même génération. Il n’est pas possible d’atteindre un consensus sur le retard, donc en fin de compte, les DAGs avec plus de preuve de travail (PoW) sont préférés à ceux avec moins de PoW ; le développeur du DAA, Bob McElrath, a analysé le problème et une atténuation possible.

  Pieter Wuille a commenté que la proposition semble similaire à une idée de 2012 d’Andrew Miller ; Zawy a convenu et McElrath mettra à jour son papier avec une citation. Sjors Provoost a discuté de la complexité de gérer les chaînes DAG dans l’architecture actuelle de Bitcoin Core, mais a noté que cela pourrait être plus facile en utilisant libbitcoin et efficace en utilisant utreexo. Zawy a simulé de manière approfondie le protocole et a indiqué qu’il travaillait sur des simulations supplémentaires pour des variantes du protocole afin de trouver le meilleur équilibre entre les compromis.

  Le dernier message du fil de discussion a été posté environ un mois avant la rédaction de ce résumé, mais nous restons en attente à ce que Zawy et les développeurs de Braidpool continuent d’analyser et d’implémenter le protocole.

Mises à jour et versions candidates

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

• ● BDK Wallet 1.1.0 est une sortie de cette bibliothèque pour la création d’applications compatibles Bitcoin. Elle utilise par défaut la version de transaction 2 (améliorant la confidentialité en permettant aux transactions BDK de se fondre avec d’autres portefeuilles qui doivent utiliser les transactions v2 en raison de leur prise en charge des verrouillages relatifs, voir le Bulletin #337). Elle ajoute également le support pour les filtres de blocs compacts (voir le Bulletin #339), en plus de “diverses corrections de bugs et améliorations”.

• ● LND v0.18.5-beta.rc1 est un candidat à la sortie pour une version mineure de cette implémentation populaire de nœud LN.

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 #21590 implémente un algorithme de modular inversion basé sur safegcd pour MuHash3072 (voir les Bulletins #131 et #136), basé sur l’implémentation de libsecp256k1 tout en ajoutant le support pour les architectures 32 bits et 64 bits et en se spécialisant pour le module spécifique. Les résultats des benchmarks montrent une amélioration de performance d’environ 100× sur x86_64, réduisant le calcul de MuHash de 5.8 ms à 57 μs, ouvrant la voie à une validation d’état plus efficace.

• ● Eclair #2983 modifie la synchronisation de la table de routage lors de la reconnexion pour seulement synchroniser les annonces de canal avec les principaux pairs du nœud (déterminés par la capacité du canal partagé) afin de réduire la surcharge réseau. De plus, le comportement par défaut de la liste blanche de synchronisation (voir le Bulletin #62) a été mis à jour : pour désactiver la synchronisation avec les pairs non listés, les utilisateurs doivent maintenant définir router.sync.peer-limit à 0 (la valeur par défaut est 5).

• ● Eclair #2968 ajoute le support pour le splicing sur les canaux publics. Une fois la transaction de splice confirmée et verrouillée des deux côtés, les nœuds échangent des signatures d’annonce puis diffusent un message channel_announcement sur le réseau. Récemment, Eclair a ajouté le suivi des splices de tiers comme prérequis pour cela (voir le Bulletin #337). Ce PR interdit également l’utilisation de short_channel_id pour le routage sur les canaux privés, privilégiant à la place scid_alias pour garantir que l’UTXO du canal n’est pas révélé.

• ● LDK #3556 améliore la gestion des HTLC en échouant proactivement les HTLCs en arrière s’ils sont trop proches de l’expiration avant d’attendre qu’une revendication onchain en amont soit confirmée. Auparavant, un nœud retarderait l’échec de l’HTLC en arrière de trois blocs supplémentaires pour donner le temps à la revendication de se confirmer. Cependant, ce délai courait le risque de fermer de force son canal. De plus, le champ historical_inbound_htlc_fulfills est supprimé pour nettoyer l’état du canal, et un nouveau SentHTLCId est introduit pour éliminer la confusion des ID HTLC en double sur les canaux entrants.

• ● LND #9456 ajoute des avertissements de dépréciation aux points de terminaison SendToRoute, SendToRouteSync, SendPayment, et SendPaymentSync en préparation de leur suppression dans la version suivante (0.21). Les utilisateurs sont encouragés à migrer vers les nouvelles méthodes v2 SendToRouteV2, SendPaymentV2, TrackPaymentV2.

Notes de bas de page

1. Dans P2SH et le comptage de sigops d’entrée proposé, un OP_CHECKMULTISIG avec plus de 16 clés publiques est compté comme 20 sigops, donc quelqu’un utilisant OP_CHECKMULTISIG 125 fois avec 17 clés chaque fois sera compté comme 2 500 sigops. ↩