Newsletter 258 translate in french (#1226)

---------

Co-authored-by: Jluc-bitcoinfr <[email protected]>

_includes/specials/policy/fr/08-interface.md

@@ -0,0 +1,89 @@
+Jusqu'à présent dans cette série, nous avons exploré les [motivations][policy01] et les défis associés à la transmission
+décentralisée des transactions, ce qui conduit à un besoin [local][policy05] et [global][policy07] de règles de validation
+des transactions plus restrictives que le consensus. Étant donné que les modifications de la politique de transmission des
+transactions dans Bitcoin Core peuvent avoir un impact sur la transmission des transactions d'une application, elles nécessitent
+une socialisation préalable avec la communauté Bitcoin plus large avant d'être prises en compte. De même, les applications
+et les protocoles de deuxième couche qui utilisent la transmission des transactions doivent être conçus en tenant compte des
+règles de politique afin d'éviter de créer des transactions qui seraient rejetées.
+
+Les protocoles de contrat dépendent encore plus étroitement des politiques liées à la priorisation, car la possibilité de les
+exécuter on chain dépend de la capacité à faire confirmer rapidement les transactions. Dans des environnements adverses,
+les contreparties malveillantes peuvent avoir intérêt à retarder la confirmation d'une transaction, il faut donc également
+réfléchir à la manière dont les particularités de l'interface de la politique de transmission des transactions peuvent être
+utilisées contre un utilisateur.
+
+Les transactions du Lightning Network respectent les règles de standardité mentionnées dans les publications précédentes. Par
+exemple, le protocole pair-à-pair spécifie une `dust_limit_satoshis` dans son message `open_channel` pour spécifier un seuil
+de poussière. Étant donné qu'une transaction contenant une sortie d'une valeur inférieure au seuil de poussière ne sera pas
+transmise en raison des limites de poussière des nœuds, ces paiements sont considérés comme "non exécutoires sur la chaîne" et
+sont supprimés des transactions d'engagement.
+
+Les protocoles de contrat utilisent souvent des chemins de dépense avec verrouillage temporel pour donner à chaque participant
+la possibilité de contester l'état publié on chain. Si l'utilisateur concerné ne parvient pas à faire confirmer une
+transaction dans ce laps de temps, il peut subir une perte de fonds. Cela rend les frais extrêmement importants en tant que
+mécanisme principal pour augmenter la priorité de confirmation, mais aussi plus difficiles à estimer. L'[estimation des frais][policy04] est
+compliquée par le fait que les transactions seront diffusées à un moment ultérieur inconnu, que les nœuds fonctionnent souvent
+en tant que clients légers et que certaines options d'augmentation des frais ne sont pas disponibles. Par exemple, si un
+participant à un canal LN se déconnecte, l'autre partie peut diffuser unilatéralement une transaction d'engagement pré-signée
+pour régler la répartition de leurs fonds partagés on chain. Aucune des parties ne peut dépenser unilatéralement l'UTXO
+partagé, donc lorsque l'une des parties est déconnectée, il n'est pas possible de signer une transaction de [remplacement][topic rbf]
+pour augmenter les frais de la transaction d'engagement. À la place, les transactions d'engagement LN peuvent inclure des
+[sorties d'ancrage][topic anchor outputs] pour que les participants au canal puissent attacher un [enfant d'augmentation des
+frais][topic cpfp] au moment de la diffusion.
+
+Cependant, cette méthode d'augmentation des frais a également des limites. Comme mentionné dans un [message précédent][policy06],
+l'ajout d'une transaction CPFP n'est pas efficace si les taux de frais minimum du mempool augmentent au-dessus du taux de frais
+de la transaction d'engagement, il est donc nécessaire de les signer avec un taux de frais légèrement surestimé au cas où les
+taux de frais minimum du mempool augmenteraient à l'avenir. De plus, le développement des sorties d'ancrage a pris en compte un
+certain nombre de considérations liées au fait qu'une partie peut avoir intérêt à retarder la confirmation. Par exemple, une
+partie (Alice) peut diffuser sa propre transaction d'engagement sur le réseau avant de se déconnecter. Si le taux de frais de
+cette transaction d'engagement est trop faible pour une confirmation immédiate et si le cocontractant d'Alice (Bob) ne reçoit pas
+sa transaction, il peut être confus lorsque ses diffusions de sa version de la transaction d'engagement ne sont pas transmises
+avec succès. Chaque transaction d'engagement comporte deux sorties d'ancrage de sorte que chaque partie puisse utiliser CPFP sur
+l'une des transactions d'engagement, par exemple, Bob peut essayer de diffuser aveuglément une augmentation des frais CPFP de la
+version d'Alice de la transaction d'engagement même s'il n'est pas sûr qu'elle ait précédemment diffusé sa version. Chaque sortie
+d'ancrage se voit attribuer une petite valeur supérieure au seuil de poussière et peut être réclamée par n'importe qui après un
+certain temps pour éviter d'encombrer l'ensemble des UTXO.
+
+Cependant, garantir la capacité de chaque partie à utiliser CPFP sur une transaction est plus compliqué que de donner à chaque
+partie une sortie d'ancrage. Comme mentionné dans un [message précédent][policy05], Bitcoin Core limite le nombre et la taille
+totale des transactions descendantes qui peuvent être attachées à une transaction non confirmée en tant que protection contre
+les attaques de déni de service. Étant donné que chaque cocontractant a la possibilité d'attacher des transactions descendantes
+à la transaction partagée, l'un pourrait bloquer la transaction CPFP de l'autre en épuisant ces limites. La présence de ces
+transactions descendantes "épingle" par conséquent la transaction d'engagement à son statut de basse priorité dans les mempools.
+
+Pour atténuer cette attaque potentielle, la proposition des sorties d'ancrage LN verrouille toutes les sorties sans ancrage avec
+un verrouillage temporel relatif, les empêchant d'être dépensées tant que la transaction n'est pas confirmée, et la politique
+de limite des transactions descendantes de Bitcoin Core a été [modifiée pour permettre une transaction descendante
+supplémentaire][topic cpfp carve out] lorsque cette nouvelle transaction descendante était de petite taille et n'avait pas d'autres
+ancêtres. Cette combinaison de modifications des deux protocoles garantit qu'au moins deux participants à une transaction partagée
+peuvent ajuster les frais au moment de la diffusion, sans augmenter de manière significative la surface d'attaque de déni de
+service de la transmission des transactions.
+
+La prévention du CPFP par domination de la limite des transactions descendantes est un exemple d'une [attaque
+d'épinglage][topic transaction pinning]. Les attaques d'épinglage exploitent les limitations de la politique des mempools pour
+empêcher les transactions compatibles avec les incitations d'entrer dans les mempools ou d'être confirmées. Dans ce cas, la
+politique des mempools a fait un compromis entre la [résistance aux attaques de déni de service][policy05] et la [compatibilité des
+incitations][policy02]. Un compromis doit être fait---un nœud doit prendre en compte les augmentations de frais mais ne peut pas
+traiter un nombre infini de transactions descendantes. Le découpage du CPFP permet d'affiner ce compromis pour un cas d'usage
+spécifique.
+
+Outre l'épuisement de la limite des transactions descendantes, il existe d'autres attaques d'épinglage qui [empêchent totalement
+l'utilisation de RBF][full rbf pinning], rendent RBF [prohibitivement coûteux][rbf ml] ou utilisent RBF pour retarder la
+confirmation d'une transaction ANYONECANPAY. L'épinglage n'est un problème que dans les scénarios où plusieurs parties collaborent
+à la création d'une transaction ou lorsqu'il y a par ailleurs une possibilité pour une partie non fiable d'interagir avec la
+transaction. Minimiser l'exposition d'une transaction à des parties non fiables est généralement un bon moyen d'éviter l'épinglage.
+
+Ces points de friction mettent en évidence non seulement l'importance de la politique en tant qu'interface pour les applications
+et les protocoles dans l'écosystème Bitcoin, mais aussi les domaines dans lesquels elle doit s'améliorer. Le prochain article de la
+semaine prochaine abordera les propositions de politique et les questions ouvertes.
+
+[full rbf pinning]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
+[rbf ml]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
+[n25038 notes]: https://bitcoincore.reviews/25038
+[policy01]: /fr/newsletters/2023/05/17/#en-attente-de-confirmation-1--pourquoi-avons-nous-un-mempool-
+[policy02]: /fr/newsletters/2023/05/24/#en-attente-de-confirmation-2--mesures-dincitation
+[policy04]: /fr/newsletters/2023/06/07/#en-attente-de-confirmation-4--estimation-du-taux-de-frais
+[policy05]: /fr/newsletters/2023/06/14/#en-attente-de-confirmation-5--politique-de-protection-des-ressources-des-nœuds
+[policy06]: /fr/newsletters/2023/06/21/#en-attente-de-confirmation-6--cohérence-des-politiques
+[policy07]: /fr/newsletters/2023/06/28/#en-attente-de-confirmation-7--ressources-du-réseau

_posts/fr/2023-05-17-policy.md

@@ -69,7 +69,13 @@ h2:not(:first-of-type) { margin-top: 3em; }
 
 {% include specials/policy/fr/07-ressources-du-reseau.md %}
 
+## La politique comme interface
+
+*Originally published in [Newsletter #258](/fr/newsletters/2023/07/05/#en-attente-de-confirmation-8--la-politique-comme-interface)*
+
+{% include specials/policy/fr/08-interface.md %}
+
 {% comment %}<!--
 ## Footnotes
 {:.no_toc}
--->{% endcomment %}
+-->{% endcomment %}

_posts/fr/newsletters/2023-07-05-newsletter.md

@@ -0,0 +1,74 @@
+---
+title: 'Bulletin Hebdomadaire Bitcoin Optech #258'
+permalink: /fr/newsletters/2023/07/05/
+name: 2023-07-05-newsletter-fr
+slug: 2023-07-05-newsletter-fr
+type: newsletter
+layout: newsletter
+lang: fr
+---
+Cette semaine, notre bulletin hebdomadaire comprend une autre contribution de notre série limitée sur la politique
+du mempool, ainsi que nos sections habituelles annonçant les nouvelles versions et les versions candidates, et
+décrivant les changements apportés aux principaux logiciels d'infrastructure Bitcoin.
+
+## Nouvelles
+
+_Aucune nouvelle significative n'a été trouvée cette semaine dans les listes de diffusion Bitcoin-Dev et Lightning-Dev._
+
+## En attente de confirmation #8 : La politique comme interface
+
+_Une [série hebdomadaire limitée][policy series] sur le relais des transactions, l'inclusion dans le mempool et la sélection
+des transactions minières---y compris pourquoi Bitcoin Core a une politique plus restrictive que celle autorisée par consensus
+et comment les portefeuilles peuvent utiliser cette politique de la manière la plus efficace._
+
+{% include specials/policy/fr/08-interface.md %} {% assign timestamp="0:30" %}
+
+## Mises à jour et versions candidates
+
+*Nouvelles versions et versions candidates pour les projets d'infrastructure Bitcoin populaires. Veuillez envisager de passer
+à de nouvelles versions ou d'aider à tester les versions candidates.*
+
+- [Core Lightning 23.05.2][] est une version de maintenance de ce logiciel de nœud LN qui contient plusieurs corrections de
+bugs qui peuvent affecter les utilisateurs en production. {% assign timestamp="10:27" %}
+
+## Changements notables dans le code et la documentation
+
+*Changements notables cette semaine dans [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo],
+[Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Interface de portefeuille matériel
+(HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [Serveur BTCPay][btcpay server repo], [BDK][bdk repo], [Propositions
+d'amélioration de Bitcoin (BIP)][bips repo], [Lightning BOLTs][bolts repo], et [Bitcoin Inquisition][bitcoin inquisition repo].*
+
+- [Bitcoin Core #24914][] charge les enregistrements de la base de données du portefeuille par type au lieu de parcourir toute
+la base de données deux fois pour détecter les dépendances. Certains portefeuilles avec des enregistrements corrompus peuvent ne
+plus se charger après cette modification, mais ils peuvent être chargés avec une version précédente de Bitcoin Core et transférés
+vers un nouveau portefeuille. {% assign timestamp="22:03" %}
+
+- [Bitcoin Core #27896][] supprime la fonctionnalité expérimentale de sandbox d'appel système (syscall) (voir
+[Bulletin #170][news170 syscall]). Un [problème connexe][Bitcoin Core #24771] et les commentaires qui ont suivi soulignent les
+inconvénients de cette fonctionnalité, notamment la maintenabilité (à la fois de la liste blanche des appels système et de la prise
+en charge du système d'exploitation), les alternatives mieux prises en charge et les considérations sur le fait de savoir si le
+sandboxing des appels système devrait être la responsabilité de Bitcoin Core. {% assign timestamp="24:47" %}
+
+- [Core Lightning #6334][] met à jour et étend le support expérimental de CLN pour les [sorties d'ancrage][topic anchor outputs]
+(voir [Bulletin #111][news111 cln anchor] pour la mise en œuvre initiale de CLN). Certaines des mises à jour de cette PR incluent
+le support expérimental des ancres [HTLC][topic htlc] sans frais et l'ajout de vérifications configurables pour s'assurer que le
+nœud dispose au moins du montant minimum de fonds d'urgence dont il a besoin pour exploiter un canal d'ancrage. {% assign timestamp="27:51" %}
+
+- [BIPs #1452][] met à jour la spécification [BIP329][] pour un format d'exportation d'étiquettes de
+[portefeuille][topic wallet labels] avec une nouvelle balise facultative `spendable` qui indique si la sortie associée doit être
+dépensable par le portefeuille. De nombreux portefeuilles mettent en œuvre des fonctionnalités de _contrôle des pièces_ qui
+permettent à un utilisateur de dire à l'algorithme de [sélection des pièces][topic coin selection] de ne pas dépenser certaines
+sorties, telles que les sorties qui pourraient réduire la confidentialité de l'utilisateur. {% assign timestamp="31:08" %}
+
+- [BIPs #1354][] ajoute [BIP389][] pour les [descripteurs][topic descriptors] de chemin de dérivation multiples décrits dans
+[Bulletin #211][news211 desc]. Il permet à un seul descripteur de spécifier deux chemins BIP32 liés pour la génération de clés
+HD---le premier chemin pour les paiements entrants et le deuxième chemin pour les paiements internes du portefeuille (comme le
+changement). {% assign timestamp="33:55" %}
+
+{% include references.md %}
+{% include linkers/issues.md v=2 issues="24914,27896,6334,1452,1354,24771" %}
+[policy series]: /fr/blog/waiting-for-confirmation/
+[news111 cln anchor]: /en/newsletters/2020/08/19/#c-lightning-3830
+[news211 desc]: /en/newsletters/2022/08/03/#multiple-derivation-path-descriptors
+[core lightning 23.05.2]: https://github.com/ElementsProject/lightning/releases/tag/v23.05.2
+[news170 syscall]: /en/newsletters/2021/10/13/#bitcoin-core-20487