La newsletter de cette semaine inclut un lien vers un article sur l’étude des réseaux de canaux de paiement. 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.

Actualités

• ● Une théorie mathématique des réseaux de canaux de paiement : René Pickhardt a publié sur Delving Bitcoin à propos de la publication de son nouvel article intitulé “A Mathematical Theory of Payment Channel Network”. Dans cet article, Pickhardt regroupe plusieurs observations, recueillies pendant des années de recherche, sous un seul cadre géométrique. En particulier, l’article vise à analyser des phénomènes communs, tels que l’épuisement des canaux (voir le Bulletin #333) et les inefficacités en capital des canaux à deux parties, en évaluant comment ils sont interconnectés et pourquoi ils sont vrais.

  Les principales contributions de l’article sont les suivantes :

  • Un modèle pour les distributions de richesse réalisables des utilisateurs sur le réseau Lightning, étant donné un graphe de canaux

  • Une formule pour estimer la limite supérieure de la bande passante de paiement pour les paiements

  • Une méthode pour estimer la probabilité qu’un paiement soit réalisable (voir le Bulletin #309)

  • Une analyse sur différentes stratégies d’atténuation pour l’épuisement des canaux

  • La conclusion que les canaux à deux parties imposent de fortes contraintes à la capacité de la liquidité à circuler entre les pairs du réseau

  Selon Pickhardt, les idées issues de sa recherche ont été la motivation derrière son récent post sur l’utilisation d’Ark comme une fabrique de canaux (voir le Bulletin #387). Pickhardt a également fourni sa collection de code, de cahiers et d’articles qui ont servi de base à sa recherche.

  Enfin, Pickhardt a ouvert la discussion sur son travail à des questions et des retours de la communauté des développeurs LN sur la manière dont la conception du protocole pourrait être influencée par sa recherche et sur la meilleure utilisation pour les canaux multi-parties.

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.

• ● Serveur Electrum pour tester les paiements silencieux : Frigate Electrum Server implémente le service de scanner à distance de BIP352 pour fournir une analyse de paiements silencieux pour les applications clientes. Frigate utilise également le calcul GPU moderne pour réduire le temps d’analyse, ce qui est utile pour fournir des instances multi-utilisateurs qui gèrent de nombreuses demandes d’analyse simultanées.

• ● Bibliothèque BDK WASM : La bibliothèque bdk-wasm, initialement développée et utilisée par l’organisation MetaMask, offre un accès aux fonctionnalités de BDK dans les environnements qui prennent en charge WebAssembly (WASM).

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.12.1 est une version de maintenance qui corrige un bug critique où les nœuds créés avec la v25.12 ne pouvaient pas dépenser des fonds envoyés à des adresses non-P2TR (voir ci-dessous). Elle corrige également les problèmes de compatibilité avec la récupération et hsmtool avec le nouveau format basé sur un mnémonique hsm_secret introduit dans la v25.12 (voir le Bulletin #388).

• ● LND 0.20.1-beta.rc1 est un candidat à la version pour une version mineure qui ajoute une récupération de panique pour le traitement des messages de gossip, améliore la protection contre les réorganisations, implémente des heuristiques de détection LSP, et corrige de multiples bugs et conditions de concurrence. Voir les notes de version pour plus de détails.

Changements notables dans le code et la documentation

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

• ● Bitcoin Core #32471 corrige un bug où appeler le RPC listdescriptors avec le paramètre private=true (voir les Bulletins #134 et #162) échouait si un descripteur avait une clé privée manquante. Ce problème affectait les portefeuilles contenant à la fois des descripteurs non seulement en observation seulement et des descripteurs simples, ainsi que des descripteurs multisig sans toutes les clés privées. Ce PR garantit que le RPC retourne correctement les clés privées disponibles, permettant aux utilisateurs de les sauvegarder correctement. Appeler listdescriptors private=true sur un portefeuille strictement en observation échoue toujours.

• ● Bitcoin Core #34146 améliore la propagation des adresses en envoyant la première auto-annonce d’un nœud dans son propre message P2P. Auparavant, l’auto-annonce était regroupée avec plusieurs autres adresses en réponse à une demande getaddr d’un pair, ce qui pourrait causer son rejet ou déplacer d’autres adresses.

• ● Core Lightning #8831 corrige un bug critique où les nœuds créés avec la v25.12 ne pouvaient pas dépenser des fonds envoyés à des adresses non-P2TR. Bien que tous les types d’adresses aient été dérivés basés sur BIP86 pour ces nœuds, le code de signature utilisait uniquement BIP86 pour les adresses P2TR. Ce PR garantit que la signature utilise la dérivation BIP86 pour tous les types d’adresses.

• ● LDK #4261 ajoute le support pour le splicing en mode mixte, permettant un splice-in et un splice-out simultanés dans la même transaction. L’entrée de financement paie les frais appropriés, comme dans le cas du splice-in. La valeur nette contribuée peut être négative si plus de valeur est splicée out que splicée in.

• ● LDK #4152 ajoute le support pour les sauts fictifs sur les chemins de paiement aveuglés, parallèlement à la fonctionnalité pour les chemins de messages aveuglés ajoutée dans le Bulletin #370. Ajouter des sauts supplémentaires rend significativement plus difficile de déterminer la distance ou l’identité du nœud récepteur. Voir le Bulletin #381 pour les travaux précédents permettant cela.

• ● LND #10488 corrige un bug où les canaux ouverts avec l’option fundMax (voir le Bulletin #246) étaient limités en taille par le paramètre maxChanSize configuré par l’utilisateur (voir le Bulletin #116), qui est censé limiter uniquement les demandes de canaux entrants. Ce PR garantit que l’option fundMax utilise la taille maximale de canal au niveau du protocole, selon que l’utilisateur et le pair prennent en charge les grands canaux.

• ● LND #10331 améliore la manière dont les fermetures de canaux gèrent les réorganisations de la blockchain en utilisant des exigences de confirmation échelonnées basées sur la taille du canal, où le minimum est de 1 et le maximum est de 6 confirmations. Le surveillant de chaîne est remanié avec l’introduction d’une machine à états pour mieux détecter les réorganisations de la blockchain et suivre les transactions de fermeture de canal concurrentes dans de tels scénarios. Le PR ajoute également une surveillance pour les confirmations négatives (lorsqu’une transaction confirmée est plus tard sortie par réorganisation), bien que la manière de les gérer reste non résolue. Ce PR aborde le plus ancien problème ouvert de LND datant de 2016.

• ● Rust Bitcoin #5402 ajoute une validation lors du décodage pour rejeter les transactions avec des entrées dupliquées, en relation avec le CVE-2018-17144. Les transactions contenant plusieurs entrées dépensant le même point de sortie sont invalides par consensus.

• ● BIPs #1820 met à jour BIP3 au statut Déployé, remplaçant BIP2 comme la directive pour le processus de Proposition d’Amélioration de Bitcoin (BIP). Voir le Bulletin #388 pour plus de détails.

• ● BOLTs #1306 clarifie dans la spécification BOLT12 que les offres avec un champ offer_chains vide doivent être rejetées. Une offre avec ce champ présent mais contenant zéro hash de chaîne rend les demandes de facture impossibles puisque le payeur ne peut pas satisfaire l’exigence de définir invreq_chain à l’un des offer_chains.

• ● BLIPs #59 met à jour BLIP51, également connu sous le nom de LSPS1, pour ajouter le support pour les offres BOLT12 comme une option pour payer les Fournisseurs de Services Lightning (LSPs), aux côtés des options BOLT11 et on-chain existantes. Cela a été précédemment implémenté dans LDK (voir le Bulletin #347).