|
| 1 | +--- |
| 2 | +title: 'Bulletin Hebdomadaire Bitcoin Optech #378' |
| 3 | +permalink: /fr/newsletters/2025/10/31/ |
| 4 | +name: 2025-10-31-newsletter-fr |
| 5 | +slug: 2025-10-31-newsletter-fr |
| 6 | +type: newsletter |
| 7 | +layout: newsletter |
| 8 | +lang: fr |
| 9 | +--- |
| 10 | +Le bulletin de cette semaine annonce quatre vulnérabilités affectant les anciennes versions du |
| 11 | +nœud complet Bitcoin Core. Sont également incluses nos sections régulières résumant les récentes |
| 12 | +questions et réponses de Bitcoin Stack Exchange, annoncant de nouvelles versions et des candidats |
| 13 | +à la publication, ainsi que les résumés des modifications notables apportées aux logiciels |
| 14 | +d'infrastructure Bitcoin populaires. |
| 15 | + |
| 16 | +## Nouvelles |
| 17 | + |
| 18 | +- **Divulgation de quatre vulnérabilités de faible gravité dans Bitcoin Core :** |
| 19 | + Antoine Poinsot a récemment [posté][poinsot disc] sur la liste de diffusion Bitcoin-Dev quatre avis |
| 20 | + de sécurité de Bitcoin Core pour des vulnérabilités de faible gravité qui ont été corrigées dans |
| 21 | + Bitcoin Core 30.0. Selon la [politique de divulgation][disc pol] (voir le [Bulletin #306][news306 |
| 22 | + disclosures]), une vulnérabilité de faible gravité est divulguée deux semaines après la sortie d'une |
| 23 | + version majeure contenant le correctif. Les quatre vulnérabilités divulguées sont les suivantes : |
| 24 | + |
| 25 | + - [Remplissage de disque par des autoconnexions falsifiées][CVE-2025-54604] : Ce bug permettrait à |
| 26 | + un attaquant de remplir l'espace disque d'un nœud victime en simulant des autoconnexions. La |
| 27 | + vulnérabilité a été [divulguée de manière responsable][topic responsible disclosures] par Niklas |
| 28 | + Gögge en mars 2022. Eugene Siegel et Niklas Gögge ont fusionné une atténuation en juillet 2025. |
| 29 | + |
| 30 | + - [Remplissage de disque par des blocs invalides][CVE-2025-54605] : Ce bug permettrait à un |
| 31 | + attaquant de remplir l'espace disque d'un nœud victime en envoyant à plusieurs reprises des blocs |
| 32 | + invalides. Ce bug a été divulgué de manière responsable par Niklas Gögge en mai 2022 et également de |
| 33 | + manière indépendante par Eugene Siegel en mars 2025. Eugene Siegel et Niklas Gögge ont fusionné |
| 34 | + l'atténuation en juillet 2025. |
| 35 | + |
| 36 | + - [Crash à distance hautement improbable sur les systèmes 32 bits][CVE-2025-46597] : Ce bug pourrait |
| 37 | + provoquer un crash d'un nœud lors de la réception d'un bloc pathologique dans un cas limite rare. Ce |
| 38 | + bug a été divulgué de manière responsable par Pieter Wuille en avril 2025. Antoine Poinsot a |
| 39 | + implémenté et fusionné l'atténuation en juin 2025. |
| 40 | + |
| 41 | + - [DoS CPU par le traitement de transaction non confirmée][CVE-2025-46598] : Ce bug causerait |
| 42 | + l'épuisement des ressources lors du traitement d'une transaction non confirmée. Ce bug a été signalé |
| 43 | + à la liste de diffusion par Antoine Poinsot en avril 2025. Pieter Wuille, Anthony Towns et Antoine |
| 44 | + Poinsot ont implémenté et fusionné l'atténuation en août 2025. |
| 45 | + |
| 46 | + Les correctifs pour les trois premières vulnérabilités ont également été inclus dans Bitcoin Core |
| 47 | + 29.1 et les versions mineures ultérieures. |
| 48 | + |
| 49 | +## Questions et réponses sélectionnées de Bitcoin Stack Exchange |
| 50 | + |
| 51 | +*[Bitcoin Stack Exchange][bitcoin.se] est l'un des premiers endroits où les contributeurs d'Optech |
| 52 | +cherchent des réponses à leurs questions---ou quand nous avons quelques moments libres pour aider |
| 53 | +les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en lumière certaines |
| 54 | +des questions et réponses les mieux votées postées depuis notre dernière mise à jour.* |
| 55 | + |
| 56 | +{% comment %}<!-- https://bitcoin.stackexchange.com/search?tab=votes&q=created%3a1m..%20is%3aanswer -->{% endcomment %} |
| 57 | +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} |
| 58 | + |
| 59 | +- [Pourquoi la taille de -datacarriersize a-t-elle été redéfinie en 2022, et pourquoi la proposition de 2023 pour l'élargir n'a-t-elle pas été fusionnée ?]({{bse}}128027) |
| 60 | + Pieter Wuille fournit un aperçu historique de la portée de l'option `-datacarriersize` de Bitcoin Core |
| 61 | + en relation avec les sorties `OP_RETURN`. |
| 62 | + |
| 63 | +- [Quelle est la transaction valide la plus petite qui peut être incluse dans un bloc ?]({{bse}}129137) |
| 64 | + Vojtěch Strnad énumère les champs minimums et les tailles qui constitueraient la |
| 65 | + transaction Bitcoin valide la plus petite possible. |
| 66 | + |
| 67 | +- [Pourquoi Bitcoin Core continue-t-il de donner un rabais sur les données de témoin même lorsqu'elles sont utilisées pour des inscriptions ?]({{bse}}128028) |
| 68 | + Pieter Wuille explique la raison d'être du rabais de témoin de segwit et souligne que le logiciel |
| 69 | + Bitcoin Core met en œuvre les règles de consensus actuelles de Bitcoin. |
| 70 | + |
| 71 | +- [La taille toujours croissante de la blockchain Bitcoin ?]({{bse}}128048) |
| 72 | + Murch note la taille actuelle de l'ensemble UTXO, les exigences de stockage pour les nœuds élagués |
| 73 | + et complets, et souligne le taux de croissance actuel de la blockchain Bitcoin. |
| 74 | + |
| 75 | +- [J'ai lu que OP_TEMPLATEHASH est une variante de OP_CTV. En quoi diffèrent-ils ?]({{bse}}128097) |
| 76 | + Rearden contraste les capacités, l'efficacité, la compatibilité, et quels champs sont hashés, entre |
| 77 | + [OP_CHECKTEMPLATEVERIFY][topic op_checktemplateverify] et la proposition récemment proposée |
| 78 | + `OP_TEMPLATEHASH` (voir le [Bulletin #365][news365 op_templatehash]). |
| 79 | + |
| 80 | +## Mises à jour et versions candidates |
| 81 | + |
| 82 | +_Nouvelles versions et versions candidates pour des projets d'infrastructure Bitcoin populaires. |
| 83 | +Veuillez envisager de mettre à niveau vers les nouvelles versions ou d'aider à tester les versions candidates._ |
| 84 | + |
| 85 | +- [LND 0.20.0-beta.rc1][] est un candidat à la sortie pour ce nœud LN populaire. Une amélioration |
| 86 | + qui bénéficierait d'un test est la correction du rescannage prématuré du portefeuille, décrite dans |
| 87 | + la section des changements de code notables ci-dessous. Voir les [notes de version][LND notes] pour |
| 88 | + plus de détails. |
| 89 | + |
| 90 | +- [Eclair 0.13.1][] est une sortie mineure de cette implémentation de nœud LN. Cette sortie contient |
| 91 | + des changements de base de données pour préparer la suppression des canaux pré-[anchor output][topic |
| 92 | + anchor outputs]. Vous devrez exécuter la version 0.13.0 d'abord pour migrer vos données de canal |
| 93 | + vers le dernier encodage interne. |
| 94 | + |
| 95 | +## Changements notables dans le code et la documentation |
| 96 | + |
| 97 | +_Changements notables récents dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core |
| 98 | +lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], |
| 99 | +[libsecp256k1][libsecp256k1 repo], [Interface de Portefeuille Matériel (HWI)][hwi repo], [Rust |
| 100 | +Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], [BDK][bdk repo], [Propositions |
| 101 | +d'Amélioration de Bitcoin (BIPs)][bips repo], [Lightning BOLTs][bolts repo], [Lightning BLIPs][blips |
| 102 | +repo], [Inquisition Bitcoin][bitcoin inquisition repo], et [BINANAs][binana repo]._ |
| 103 | + |
| 104 | +- [Bitcoin Core #29640][] réinitialise les valeurs de `nSequenceId` au démarrage pour les blocs sur |
| 105 | + des chaînes concurrentes ayant le même montant de travail : 0 pour les blocs appartenant à la |
| 106 | + meilleure chaîne précédemment connue, et 1 pour tous les autres blocs chargés. Cela résout un |
| 107 | + problème où Bitcoin Core ne pouvait pas effectuer un départage entre deux chaînes concurrentes |
| 108 | + parce que la valeur `nSequenceId` ne persistait pas à travers les redémarrages. |
| 109 | + |
| 110 | +- [Core Lightning #8400][] introduit un nouveau format de sauvegarde mnémonique [BIP39][] pour le |
| 111 | + `hsm_secret` avec une passphrase optionnelle pour tous les nouveaux nœuds par défaut, tout en |
| 112 | + conservant le support pour les `hsm_secrets` de 32 octets existants. `Hsmtool` est également mis à |
| 113 | + jour pour supporter les secrets basés sur des mnémoniques et les secrets traditionnels. Un nouveau |
| 114 | + format de dérivation standard [taproot][topic taproot] est introduit pour les portefeuilles. |
| 115 | + |
| 116 | +- [Eclair #3173][] supprime le support pour les canaux hérités qui n'utilisent pas les [anchor |
| 117 | + outputs][topic anchor outputs] ou [taproot][topic taproot], également connus sous le nom de canaux |
| 118 | + `static_remotekey` ou `default`. Les utilisateurs devraient fermer tous les canaux hérités restants |
| 119 | + avant de passer à la version 0.13 ou 0.13.1. |
| 120 | + |
| 121 | +- [LND #10280][] attend désormais que les en-têtes soient synchronisés avant de démarrer le |
| 122 | + notificateur de chaîne (voir le [Bulletin #31][news31 chain]) pour rescanner la chaîne pour les |
| 123 | + transactions de portefeuille. Cela résout un problème dans lequel LND déclenchait un rescannage |
| 124 | + prématuré alors que les en-têtes étaient encore en cours de synchronisation lorsqu'un nouveau |
| 125 | + portefeuille était créé. Cela affectait principalement les [backends Neutrino][topic compact block filters]. |
| 126 | + |
| 127 | +- [BIPs #2006][] met à jour la spécification de [BIP3][] (voir le [Bulletin #344][news344 bip3]) en |
| 128 | + ajoutant des conseils sur l'originalité et la qualité, en particulier en conseillant aux auteurs de |
| 129 | + ne pas générer de contenu avec des IA/LLM, et en encourageant la divulgation proactive de |
| 130 | + l'utilisation des IA/LLM. |
| 131 | + |
| 132 | +- [BIPs #1975][] met à jour [BIP155][] qui spécifie [addr v2][topic addr v2], une nouvelle version |
| 133 | + du message `addr` dans le protocole réseau P2P de Bitcoin, en ajoutant une note indiquant que [Tor |
| 134 | + v2][topic anonymity networks] n'est plus opérationnel. |
| 135 | + |
| 136 | +{% include snippets/recap-ad.md when="2025-11-04 16:30" %} |
| 137 | +{% include references.md %} |
| 138 | +{% include linkers/issues.md v=2 issues="29640,8400,3173,10280,5516,2006,1975" %} |
| 139 | + |
| 140 | +[poinsot disc]: https://groups.google.com/g/bitcoindev/c/sBpCgS_yGws |
| 141 | +[disc pol]: https://bitcoincore.org/en/security-advisories/ |
| 142 | +[news306 disclosures]: /fr/newsletters/2024/06/07/#divulgation-a-venir-de-vulnerabilites-affectant-les-anciennes-versions-de-bitcoin-core |
| 143 | +[CVE-2025-54604]: https://bitcoincore.org/en/2025/10/24/disclose-cve-2025-54604/ |
| 144 | +[CVE-2025-54605]: https://bitcoincore.org/en/2025/10/24/disclose-cve-2025-54605/ |
| 145 | +[CVE-2025-46597]: https://bitcoincore.org/en/2025/10/24/disclose-cve-2025-46597/ |
| 146 | +[CVE-2025-46598]: https://bitcoincore.org/en/2025/10/24/disclose-cve-2025-46598/ |
| 147 | +[LND 0.20.0-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.20.0-beta.rc2 |
| 148 | +[LND notes]: https://github.com/lightningnetwork/lnd/blob/master/docs/release-notes/release-notes-0.20.0.md |
| 149 | +[Eclair 0.13.1]: https://github.com/ACINQ/eclair/releases/tag/v0.13.1 |
| 150 | +[news31 chain]: /en/newsletters/2019/01/29/#lnd-2314 |
| 151 | +[news344 bip3]: /fr/newsletters/2025/03/07/#bips-1712 |
| 152 | +[news365 op_templatehash]: /fr/newsletters/2025/08/01/#proposition-de-op-templatehash-natif-a-taproot |
0 commit comments