From 44690eb7f0ad6642618b14612a350621151a174d Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Fri, 3 Apr 2026 19:50:23 +0200 Subject: [PATCH 1/2] Create 2026-04-03-newsletter.md --- .../fr/newsletters/2026-04-03-newsletter.md | 201 ++++++++++++++++++ 1 file changed, 201 insertions(+) create mode 100644 _posts/fr/newsletters/2026-04-03-newsletter.md diff --git a/_posts/fr/newsletters/2026-04-03-newsletter.md b/_posts/fr/newsletters/2026-04-03-newsletter.md new file mode 100644 index 000000000..ecdf711e3 --- /dev/null +++ b/_posts/fr/newsletters/2026-04-03-newsletter.md @@ -0,0 +1,201 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #399' +permalink: /fr/newsletters/2026/04/03/ +name: 2026-04-03-newsletter-fr +slug: 2026-04-03-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine décrit comment l'empreinte des portefeuilles peut nuire à la confidentialité de payjoin et résume une +proposition de format de métadonnées pour la sauvegarde de portefeuilles. Sont également incluses nos rubriques habituelles résumant les +propositions et discussions sur la modification des règles de consensus de Bitcoin, annonçant de nouvelles versions et versions candidates, +et décrivant les changements notables apportés aux logiciels populaires d'infrastructure Bitcoin. + +## Nouvelles + +- **Risques de l'empreinte des portefeuilles pour la confidentialité de payjoin** : Armin Sabouri a [posté][topic payjoin fingerprinting] + sur Delving Bitcoin comment des différences dans les implémentations de payjoin permettent de prendre l'empreinte des transactions + [payjoin][topic payjoin] et peuvent nuire à la confidentialité de payjoin. + + Sabouri indique que les transactions payjoin devraient paraître indiscernables de transactions standard à partie unique. Cependant, il + peut y avoir des artefacts de transactions collaboratives : + + - Intra-transaction + + - Partitionner les entrées et sorties par propriétaire au sein d'une même transaction. + + - Différences dans l'encodage des entrées. + + - Longueur des entrées en octets. + + - Inter-transaction + + - Rétrospective : chaque entrée a été créée par une transaction antérieure qui porte sa propre empreinte. + + - Prospective : chaque sortie peut être dépensée dans une transaction future, révélant des empreintes. + + Il a ensuite examiné trois implémentations de payjoin : Samourai, la démo PDK, et Cake Wallet (envoyant vers Bull Bitcoin Mobile). Dans + chacun de ces exemples, il trouve quelques divergences qui permettent de prendre l'empreinte de ces implémentations. Cela inclut, sans s'y + limiter : + + - Différences dans les signatures d'entrée encodées. + + - L'octet SIGHASH_ALL inclus dans une entrée mais pas dans l'autre. + + - Attribution de la valeur des sorties. + + Sabouri conclut que, si certaines de ces empreintes de portefeuille sont triviales à éliminer, d'autres sont intrinsèques à un choix de + conception particulier du portefeuille. Les développeurs de portefeuilles devraient être conscients de ces fuites potentielles de + confidentialité lors de l'implémentation de payjoin dans leurs portefeuilles. + +- **Projet de BIP pour un format de métadonnées de sauvegarde de portefeuille** : Pythcoiner a [posté][wallet bip ml] sur la liste de + diffusion Bitcoin-Dev une nouvelle proposition pour une structure commune de métadonnées de sauvegarde de portefeuille. Le projet de BIP, + disponible dans [BIPs #2130][], spécifie une manière standard de stocker divers types de métadonnées, comme les descripteurs de compte, + les clés, les [étiquettes][topic wallet labels], les [PSBT][topic psbt], et plus encore, permettant la compatibilité entre différentes + implémentations de portefeuilles ainsi que des processus de migration et de récupération de portefeuille plus simples. Selon Pythcoiner, + l'écosystème manque d'une spécification commune et cette proposition vise à combler cette lacune. + + D'un point de vue technique, le format proposé est un fichier texte encodé en UTF-8 contenant un unique objet JSON valide représentant la + structure de sauvegarde. Le BIP énumère tous les différents champs pouvant être inclus dans l'objet JSON, précise que chacun d'eux est + optionnel, et note que toute implémentation de portefeuille devrait être libre d'ignorer toute métadonnée jugée inutile. + +## Modification du consensus + +_Une nouvelle section mensuelle résumant les propositions et discussions sur la modification des règles de consensus de Bitcoin._ + +- **Compact Isogeny PQC peut remplacer les portefeuilles HD, l'ajustement de clé, les silent payments** : Conduition a [écrit][c delving ibc + hd] sur Delving Bitcoin à propos de ses recherches sur l'adéquation de la cryptographie basée sur les isogénies (IBC) comme système + cryptographique [post-quantique][topic quantum resistance] pour Bitcoin. Alors que le problème du logarithme discret sur courbe elliptique + (ECDLP) pourrait devenir non sécurisé dans un monde post-quantique, il n'y a rien de fondamentalement cassé dans les mathématiques des + courbes elliptiques en général. Brièvement, une isogénie est une application d'une courbe elliptique vers une autre. L'hypothèse + cryptographique de l'IBC est qu'il est difficile de calculer l'isogénie entre une courbe elliptique d'un type spécifique et une autre, + alors qu'il est facile de produire une isogénie et la courbe vers laquelle elle applique depuis une courbe de base. Ainsi, les clés + secrètes IBC sont des isogénies et les clés publiques sont les courbes obtenues. + + Comme avec les clés secrètes et publiques ECDLP, il est possible de calculer de nouvelles clés secrètes et de nouvelles clés publiques + indépendamment à partir du même sel (par ex. une étape de [dérivation BIP32][topic bip32]) et que les clés secrètes résultantes signent + correctement pour les clés publiques résultantes. Conduition appelle cela la « rerandomisation » et cela permet fondamentalement + [BIP32][], [BIP341][] et [BIP352][] (avec probablement quelques innovations cryptographiques supplémentaires). + + À ce jour, il n'existe pas de protocoles d'agrégation de signatures pour l'IBC comme il en existe pour [MuSig][topic musig] et + [FROST][topic threshold signature], et conduition lance un appel à l'action aux développeurs Bitcoin et cryptographes pour étudier ce qui + pourrait être possible. + + Les clés et signatures dans les systèmes cryptographiques IBC connus font environ deux fois la taille des clés dans les systèmes + cryptographiques dépendant de l'ECDLP. Bien plus petites que dans les systèmes cryptographiques basés sur le hachage ou sur les réseaux + euclidiens. La vérification est coûteuse même sur des machines de bureau (de l'ordre de 1 milliseconde par vérification), dans la même + gamme que les systèmes basés sur le hachage et sur les réseaux euclidiens. + +- **Le budget varops et la feuille tapscript 0xc2 (alias "Script Restoration") sont les BIP 440 et 441** : Rusty Russell a [écrit][rr ml gsr + bips] sur la liste de diffusion Bitcoin-Dev que les deux premiers BIP de la Great Script Restoration (ou Grand Script Renaissance) ont été + soumis pour l'attribution d'un numéro BIP. Ils ont ensuite reçu les numéros BIP 440 et 441 respectivement. [BIP440][news374 varops] permet + la restauration d'opcodes Script précédemment désactivés en construisant un système de comptabilité du coût de chaque opération qui + garantit que le pire coût de validation de script au niveau d'un bloc ne peut pas dépasser le coût de validation d'un bloc contenant le + pire nombre possible d'opérations de signature. [BIP441][news374 c2] décrit la validation d'une nouvelle version de [tapscript][topic + tapscript] qui restaure les opcodes désactivés par Satoshi en 2010. + +- **SHRIMPS : signatures post-quantiques de 2,5 Ko sur plusieurs appareils à état** : Jonas Nick [écrit][jn delving shrimps] sur Delving + Bitcoin à propos d'une nouvelle construction de signature semi-étatique basée sur le hachage pour un Bitcoin post-quantique. SHRIMPS tire + parti du fait que les tailles de signature [SPHINCS+][news383 sphincs] évoluent avec le nombre maximal de signatures pour une clé donnée + qui peuvent être produites tout en conservant un niveau de sécurité donné. + + Semblable au design [SHRINCS][news391 shrincs], une clé SHRIMPS est composée de deux clés hachées ensemble. Dans ce cas, les deux clés + sont des clés SPHINCS+ sans état, mais avec des jeux de paramètres différents. La première clé n'est sécurisée que pour un petit nombre de + signatures et est destinée à être utilisée avec la première (ou les quelques premières) signatures de chaque appareil de signature avec + lequel la clé est utilisée. La seconde clé est sécurisée pour un nombre bien plus important de signatures (effectivement illimité dans un + contexte Bitcoin) et chaque appareil revient sur cette clé après un certain nombre (potentiellement choisi par l'utilisateur) de + signatures depuis cet appareil. Il en résulte que, dans le cas d'usage courant de Bitcoin où une clé donnée (dont beaucoup peuvent être + dérivées d'une seule graine) ne signe qu'un petit nombre de fois, presque toutes les signatures peuvent faire < 2,5 Ko tout en n'ayant + toujours aucune limite effective sur le nombre total de signatures si une clé finit par être réutilisée de nombreuses fois, au prix de + signatures plus tardives d'environ 7,5 Ko. SHRIMPS est semi-étatique dans le sens où aucun état global n'a besoin d'être conservé, mais + chaque appareil de signature doit enregistrer quelques bits d' état pour chaque clé SHRIMPS avec laquelle il signe ((jusqu’à un seul bit + seulement, si seule la première signature pour chaque couple appareil–clé bénéficie de la signature compacte). + +## 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 31.0rc2][] est une version candidate pour la prochaine version majeure de l'implémentation de nœud complet prédominante. Un + [guide de test][bcc31 testing] est disponible. + +- [Core Lightning 26.04rc2][] est la plus récente version candidate pour la prochaine version majeure de ce nœud LN populaire, poursuivant + les mises à jour du splicing et les corrections de bogues des versions candidates précédentes. + +- [BTCPay Server 2.3.7][] est une version mineure de cette solution de paiement auto-hébergée qui fait migrer le projet vers .NET 10, ajoute + des améliorations au passage en caisse des abonnements et des factures, ainsi que plusieurs autres améliorations et corrections de bogues. + Les développeurs de plugins devraient suivre le [guide de migration .NET 10][btcpay net10] du projet lors de la mise à jour. + +## Changements notables dans le code et la documentation + +_Changements récents notables 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], [Bitcoin Improvement Proposals (BIPs)][bips repo], [Lightning +BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo], et [BINANAs][binana repo]._ + +- [Bitcoin Core #32297][] ajoute une option `-ipcconnect` à `bitcoin-cli` afin qu'il puisse se connecter à une instance `bitcoin-node` et la + contrôler via une communication inter-processus (IPC) sur un socket Unix au lieu de HTTP lorsque Bitcoin Core est compilé avec + `ENABLE_IPC` et que le nœud est démarré avec `-ipcbind` (voir les bulletins [#320][news320 ipc] et [#369][news369 ipc]). Même lorsque + `-ipcconnect` est omise, `bitcoin-cli` essaie d'abord l'IPC puis revient à HTTP si l'IPC n'est pas disponible. Cela fait partie du [projet + de séparation multiprocessus][multiprocess]. + +- [Bitcoin Core #34379][] corrige un bogue où l'appel RPC `gethdkeys` (voir le [Bulletin #297][news297 rpc]) avec `private=true` échouait si le + portefeuille contenait un [descripteur][topic descriptors] dont il possédait certaines clés privées mais pas toutes. Semblable au + correctif pour `listdescriptors` (voir le [Bulletin #389][news389 descriptor]), cette PR renvoie les clés privées disponibles. Appeler + `gethdkeys private=true` sur un portefeuille strictement en observation seule échoue toujours. + +- [Eclair #3269][] ajoute la récupération automatique de liquidité depuis des canaux inactifs. Lorsque le `PeerScorer` détecte que le volume + total de paiements d'un canal dans les deux directions tombe en dessous de 5 % de sa capacité, il réduit progressivement les [frais de + relais][topic inbound forwarding fees] jusqu'au minimum configuré. Si les frais sont au minimum depuis au moins cinq jours et que le + volume n'a toujours pas repris, Eclair ferme le canal lorsqu'il est redondant avec ce pair. Les canaux ne sont fermés que si le nœud + détient au moins 25 % des fonds et que le solde local dépasse le paramètre existant `localBalanceClosingThreshold`. + +- [LDK #4486][] fusionne le point de terminaison `rbf_channel` dans `splice_channel` comme point d'entrée unique à la fois pour les nouveaux + [splices][topic splicing] et pour l'augmentation de frais d'un splice en cours. Lorsqu'un splice est déjà en cours, le `FundingTemplate` + renvoyé par `splice_channel` contient `PriorContribution` afin que les utilisateurs puissent [RBF][topic rbf] le splice sans nouvelle + [sélection de pièces][topic coin selection]. Voir le [Bulletin #397][news397 rbf] pour un comportement RBF de splice connexe. + +- [LDK #4428][] ajoute la prise en charge de l'ouverture et de l'acceptation de canaux avec une réserve de canal nulle via une nouvelle + méthode `create_channel_to_trusted_peer_0reserve` pour les pairs de confiance. Les canaux à réserve nulle permettent à la contrepartie de + dépenser l'intégralité de son solde on-chain dans le canal. Cela est activé aussi bien pour les canaux utilisant des [anchor + outputs][topic anchor outputs] que pour les canaux de commitment sans frais (voir le [Bulletin #371][news371 0fc]). + +- [LND #9982][], [#10650][lnd #10650] et [#10693][lnd #10693] renforcent la gestion des nonce [MuSig2][topic musig] sur le réseau pour les + canaux [taproot][topic taproot] : `ChannelReestablish` gagne un champ `LocalNonces` afin que les pairs puissent coordonner plusieurs nonce + pour les mises à jour liées au [splicing][topic splicing], `lnwire` valide les nonce publics MuSig2 lors du décodage TLV pour les messages + transportant des nonce, et le décodage de `LocalNoncesData` valide chaque entrée de nonce. + +- [LND #10063][] étend le flux de fermeture coopérative [RBF][topic rbf] aux [canaux taproot simples][topic simple taproot channels] en + utilisant [MuSig2][topic musig]. Les messages wire transportent des champs de nonce et de signature partielle spécifiques à + [taproot][topic taproot], et la machine à états de fermeture utilise des sessions MuSig2 avec un modèle de nonce juste-à-temps à travers + `shutdown`, `closing_complete` et `closing_sig` (voir le [Bulletin #347][news347 rbf coop] pour le contexte sur le flux de fermeture + coopérative RBF). + +{% include snippets/recap-ad.md when="2026-04-07 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="2130,32297,34379,3269,4486,4428,9982,10650,10693,10063" %} + +[topic payjoin]: /en/topics/payjoin/ +[topic payjoin fingerprinting]: https://delvingbitcoin.org/t/how-wallet-fingerprints-damage-payjoin-privacy/2354 +[c delving ibc hd]: https://delvingbitcoin.org/t/compact-isogeny-pqc-can-replace-hd-wallets-key-tweaking-silent-payments/2324 +[rr ml gsr bips]: https://groups.google.com/g/bitcoindev/c/T8k47suwuOM +[news374 varops]: /fr/newsletters/2025/10/03/#brouillons-de-bip-pour-la-restauration-de-script +[news374 c2]: /fr/newsletters/2025/10/03/#brouillons-de-bip-pour-la-restauration-de-script +[jn delving shrimps]: https://delvingbitcoin.org/t/shrimps-2-5-kb-post-quantum-signatures-across-multiple-stateful-devices/2355 +[news383 sphincs]: /en/newsletters/2025/12/05/#optimisations-de-signature-post-quantique-slh-dsa-sphincs +[news391 shrincs]: /en/newsletters/2026/02/06/#shrincs-signatures-post-quantiques-etatiques-de-324-octets-avec-sauvegardes-statiques +[wallet bip ml]: https://groups.google.com/g/bitcoindev/c/ylPeOnEIhO8 +[news297 rpc]: /fr/newsletters/2024/04/10/#bitcoin-core-29130 +[news320 ipc]: /fr/newsletters/2024/09/13/#bitcoin-core-30509 +[news347 rbf coop]: /fr/newsletters/2025/03/28/#lnd-8453 +[news369 ipc]: /fr/newsletters/2025/08/29/#bitcoin-core-31802 +[news371 0fc]: /fr/newsletters/2025/09/12/#ldk-4053 +[news389 descriptor]: /fr/newsletters/2026/01/23/#bitcoin-core-32471 +[news397 rbf]: /fr/newsletters/2026/03/20/#ldk-4427 +[multiprocess]: https://github.com/bitcoin/bitcoin/issues/28722 +[bitcoin core 31.0rc2]: https://bitcoincore.org/bin/bitcoin-core-31.0/test.rc2/ +[Core Lightning 26.04rc2]: https://github.com/ElementsProject/lightning/releases/tag/v26.04rc2 +[BTCPay Server 2.3.7]: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.3.7 +[bcc31 testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/31.0-Release-Candidate-Testing-Guide +[btcpay net10]: https://blog.btcpayserver.org/migrating-to-net10/ From 38d70887e8532ec577bc7cabbdca7e7658c9d718 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Fri, 3 Apr 2026 20:03:25 +0200 Subject: [PATCH 2/2] Update 2026-04-03-newsletter.md --- _posts/fr/newsletters/2026-04-03-newsletter.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/fr/newsletters/2026-04-03-newsletter.md b/_posts/fr/newsletters/2026-04-03-newsletter.md index ecdf711e3..15b33968e 100644 --- a/_posts/fr/newsletters/2026-04-03-newsletter.md +++ b/_posts/fr/newsletters/2026-04-03-newsletter.md @@ -183,8 +183,8 @@ BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin [news374 varops]: /fr/newsletters/2025/10/03/#brouillons-de-bip-pour-la-restauration-de-script [news374 c2]: /fr/newsletters/2025/10/03/#brouillons-de-bip-pour-la-restauration-de-script [jn delving shrimps]: https://delvingbitcoin.org/t/shrimps-2-5-kb-post-quantum-signatures-across-multiple-stateful-devices/2355 -[news383 sphincs]: /en/newsletters/2025/12/05/#optimisations-de-signature-post-quantique-slh-dsa-sphincs -[news391 shrincs]: /en/newsletters/2026/02/06/#shrincs-signatures-post-quantiques-etatiques-de-324-octets-avec-sauvegardes-statiques +[news383 sphincs]: /fr/newsletters/2025/12/05/#optimisations-de-signature-post-quantique-slh-dsa-sphincs +[news391 shrincs]: /fr/newsletters/2026/02/06/#shrincs-signatures-post-quantiques-etatiques-de-324-octets-avec-sauvegardes-statiques [wallet bip ml]: https://groups.google.com/g/bitcoindev/c/ylPeOnEIhO8 [news297 rpc]: /fr/newsletters/2024/04/10/#bitcoin-core-29130 [news320 ipc]: /fr/newsletters/2024/09/13/#bitcoin-core-30509