diff --git a/_posts/fr/newsletters/2026-01-23-newsletter.md b/_posts/fr/newsletters/2026-01-23-newsletter.md new file mode 100644 index 000000000..efc469ebf --- /dev/null +++ b/_posts/fr/newsletters/2026-01-23-newsletter.md @@ -0,0 +1,186 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #389' +permalink: /fr/newsletters/2026/01/23/ +name: 2026-01-23-newsletter-fr +slug: 2026-01-23-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +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é][channels post] sur Delving Bitcoin à propos de la publication de son nouvel + [article][channels paper] 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][news333 depletion]) 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][news309 feasibility]) + + - Une analyse sur différentes + [stratégies d'atténuation][mitigation post] 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][new387 ark]). Pickhardt a + également fourni sa [collection][pickhardt gh] 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][frigate gh] implémente le service de [scanner à distance][bip352 remote + scanner] de [BIP352][] pour fournir une analyse de [paiements silencieux][topic silent payments] + 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][bdk-wasm gh], initialement développée et [utilisée][metamask blog] 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][topic + taproot] (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][news388 cln]). + +- [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][bitcoin core repo], [Core Lightning][core +lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], +[libsecp256k1][libsecp256k1 repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust +bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Propositions d'Amélioration de +Bitcoin (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], +[Inquisition Bitcoin][bitcoin inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #32471][] corrige un bug où appeler le RPC `listdescriptors` avec le paramètre + `private=true` (voir les Bulletins [#134][news134 descriptor] et [#162][news162 descriptor]) échouait + si un [descripteur][topic descriptors] 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][topic taproot]. 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][topic 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][topic rv routing], parallèlement à la fonctionnalité pour les chemins de messages + aveuglés ajoutée dans le [Bulletin #370][news370 dummy]. 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][news381 dummy] 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][news246 fundmax]) étaient limités en taille par le paramètre `maxChanSize` configuré par + l'utilisateur (voir le [Bulletin #116][news116 maxchan]), 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][topic large channels]. + +- [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][lnd issue] 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][topic 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][news388 + bip3] pour plus de détails. + +- [BOLTs #1306][] clarifie dans la spécification [BOLT12][] que [les offres][topic offers] 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][topic offers] 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][news347 lsp]). + +{% include snippets/recap-ad.md when="2026-01-27 17:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="32471,34146,8831,4261,4152,10488,10331,5402,1820,1306,59" %} + +[channels post]: https://delvingbitcoin.org/t/a-mathematical-theory-of-payment-channel-networks/2204 +[channels paper]: https://arxiv.org/pdf/2601.04835 +[news309 feasibility]: /fr/newsletters/2024/06/28/#estimation-de-la-probabilite-qu-un-paiement-ln-soit-realisable +[mitigation post]: https://delvingbitcoin.org/t/mitigating-channel-depletion-in-the-lightning-network-a-survey-of-potential-solutions/1640/1 +[news333 depletion]: /fr/newsletters/2024/12/13/#apercus-sur-l-epuisement-des-canaux +[new387 ark]: /fr/newsletters/2026/01/09/#utiliser-ark-comme-une-fabrique-de-canaux +[pickhardt gh]: https://github.com/renepickhardt/Lightning-Network-Limitations +[frigate gh]: https://github.com/sparrowwallet/frigate +[bip352 remote scanner]: https://github.com/silent-payments/BIP0352-index-server-specification/blob/main/README.md#remote-scanner-ephemeral +[bdk-wasm gh]: https://github.com/bitcoindevkit/bdk-wasm +[metamask blog]: https://metamask.io/news/bitcoin-on-metamask-btc-wallet +[Core Lightning 25.12.1]: https://github.com/ElementsProject/lightning/releases/tag/v25.12.1 +[LND 0.20.1-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.20.1-beta.rc1 +[news388 cln]: /fr/newsletters/2026/01/16/#core-lightning-8830 +[notes de version]: https://github.com/lightningnetwork/lnd/blob/v0.20.x-branch/docs/release-notes/release-notes-0.20.1.md +[news134 descriptor]: /en/newsletters/2021/02/03/#bitcoin-core-20226 +[news162 descriptor]: /en/newsletters/2021/08/18/#bitcoin-core-21500 +[news370 dummy]: /fr/newsletters/2025/09/05/#ldk-3726 +[news381 dummy]: /fr/newsletters/2025/11/21/#ldk-4126 +[news246 fundmax]: /fr/newsletters/2023/04/26/#lnd-6903 +[news116 maxchan]: /en/newsletters/2020/09/23/#lnd-4567 +[lnd issue]: https://github.com/lightningnetwork/lnd/issues/53 +[news388 bip3]: /fr/newsletters/2026/01/16/#processus-bip-mis-a-jour +[news347 lsp]: /fr/newsletters/2025/03/28/#ldk-3649 \ No newline at end of file