Skip to content

Commit 0281e1b

Browse files
Newsletter 313 translate in French (#1833)
Co-authored-by: Jluc-bitcoinfr <[email protected]>
1 parent 9745e0e commit 0281e1b

File tree

1 file changed

+249
-0
lines changed

1 file changed

+249
-0
lines changed
Lines changed: 249 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,249 @@
1+
---
2+
title: 'Bulletin Hebdomadaire Bitcoin Optech #313'
3+
permalink: /fr/newsletters/2024/07/26/
4+
name: 2024-07-26-newsletter-fr
5+
slug: 2024-07-26-newsletter-fr
6+
type: newsletter
7+
layout: newsletter
8+
lang: fr
9+
---
10+
Le bulletin de cette semaine résume une vaste discussion sur le relai gratuit et les
11+
améliorations du bumping de frais dans Bitcoin Core. Sont également incluses nos
12+
rubriques habituelles avec des questions et réponses populaires
13+
de la communauté Bitcoin Stack Exchange, des annonces de nouvelles versions et de
14+
versions candidates, ainsi que les changements apportés aux principaux logiciels d'infrastructure Bitcoin.
15+
16+
## Nouvelles
17+
18+
- **Discussion variée sur le relai gratuit et les améliorations du bumping de frais :** Peter Todd
19+
a [posté][todd fr-rbf] sur la liste de diffusion Bitcoin-Dev un résumé d'une attaque de relai
20+
gratuit qu'il avait précédemment [divulguée de manière responsable][topic responsible disclosures]
21+
aux développeurs de Bitcoin Core. Cela a mené à une discussion complexe sur de multiples problèmes
22+
et améliorations proposées. Voilà quelques-uns des thèmes abordés :
23+
24+
- *Attaques de relai gratuit :* le [relai gratuit][topic free relay] se produit lorsqu'un nœud
25+
complet relaye des transactions non confirmées sans que le montant des revenus de frais dans son
26+
mempool n'augmente d'au moins le taux de relai minimum (par défaut, 1 sat/vbyte). Le relai gratuit
27+
coûte souvent de l'argent, donc il n'est pas techniquement gratuit, mais le coût est bien inférieur
28+
à ce que les utilisateurs honnêtes paient pour le relai.
29+
30+
Le relai gratuit permet à un attaquant d'augmenter considérablement la bande passante utilisée par
31+
les nœuds de relais, ce qui peut réduire le nombre de nœuds de relais. Si le nombre de nœuds de
32+
relais exploités indépendamment devient trop faible, ceux qui effectuent la dépense envoient essentiellement des
33+
transactions directement aux mineurs, ce qui présente les mêmes risques de centralisation que les
34+
[frais hors bande][topic out-of-band fees].
35+
36+
L'attaque décrite par Todd exploite les différences de politique de mempool entre les mineurs et les
37+
utilisateurs. De nombreux mineurs semblent activer le [full-RBF][topic rbf] mais Bitcoin Core ne
38+
l'active pas par défaut (voir le [Bulletin #263][news263 full-rbf]). Cela permet à un attaquant de
39+
créer différentes versions d'une transaction qui seront traitées différemment par les mineurs
40+
full-RBF et les nœuds de relais non-full-RBF. Les nœuds de relais peuvent finir par relayer
41+
plusieurs versions d'une transaction qui ont peu de chances de se confirmer, gaspillant ainsi la
42+
bande passante des nœuds de relais.
43+
44+
Les attaques de relai gratuit ne permettent pas directement aux attaquants de voler les fonds
45+
d'autres utilisateurs, bien qu'une attaque soudaine ou prolongée puisse être utilisée pour perturber
46+
le réseau et faciliter d'autres types d'attaques. À notre connaissance, aucune attaque de relai
47+
gratuit perturbatrice n'a jamais été réalisée.
48+
49+
- *Relai gratuit et replace-by-feerate :* Peter Todd a précédemment proposé deux formes de
50+
replace-by-feerate (RBFR) ; voir le [Bulletin #288][news288 rbfr]. Une critique du RBFR était qu'il
51+
permettait le relai gratuit. Une quantité similaire de relai gratuit est déjà possible à travers
52+
l'attaque qu'il a décrite cette semaine et des attaques similaires, donc il a argumenté que les
53+
préoccupations concernant le relai gratuit ne devraient pas bloquer l'ajout d'une fonctionnalité
54+
utile pour atténuer les [attaques par épinglage de transaction][topic transaction pinning].
55+
56+
Une [réponse][harding rbfr fundamental] a argumenté que le relai gratuit créé par le RBFR était
57+
fondamental à sa conception, mais d'autres problèmes de relai gratuit dans la conception de Bitcoin
58+
Core pourraient être solutionnables. Todd [n'était pas d'accord][todd unsolvable].
59+
60+
- *Utilité de TRUC :* Peter Todd a argumenté que [TRUC][topic v3 transaction relay] était une
61+
"mauvaise proposition". Il avait précédemment critiqué le protocole (voir le [Bulletin #283][news283
62+
truc pin]) et spécifiquement critiqué la spécification de TRUC, [BIP431][], qui exploite les
63+
inquiétudes concernant le relai gratuit pour plaider en faveur de TRUC plutôt que sa propre
64+
proposition RBFR.
65+
66+
Cependant, BIP431 argumente également contre des versions de RBFR, telles que le RBFR en une seule
67+
fois de Todd, qui dépendent du paiement d'un taux de frais suffisamment élevé pour qu'il devienne
68+
l'une des transactions les plus rentables à miner dans les prochains blocs, décrit comme entrant
69+
dans la partie supérieure du mempool. Todd et d'autres ont convenu que cela serait beaucoup plus
70+
facile à réaliser une fois que Bitcoin Core commencera à utiliser le [cluster de mempool][topic cluster
71+
mempool], bien que Todd ait également suggéré des méthodes alternatives disponibles dès maintenant.
72+
TRUC n'a pas besoin d'informations sur la partie supérieure du mempool, donc il ne dépend pas du
73+
cluster de mempool ou des alternatives.
74+
75+
Une forme plus longue de cette critique a été résumée dans le [Bulletin #288][news288 rbfr], avec des
76+
recherches ultérieures (résumées dans le [Bulletin #290][news290 rbf]) illustrant à quel point il est
77+
difficile pour tout ensemble de règles de remplacement de transactions de toujours faire un choix
78+
qui améliorera la rentabilité des mineurs. Par rapport à RBFR, TRUC ne change pas les règles de
79+
remplacement de Bitcoin Core (sauf pour toujours permettre que les remplacements soient considérés
80+
pour les transactions TRUC), donc cela ne devrait pas aggraver les problèmes existants avec la
81+
compatibilité des incitations au remplacement.
82+
83+
- *Chemin vers un cluster de mempool :* comme décrit dans le [Bulletin #285][news285 cluster cpfp-co], la
84+
proposition de [cluster de mempool][topic cluster mempool] nécessite de désactiver [CPFP
85+
carve-out][topic cpfp carve out] (CPFP-CO), qui est actuellement utilisé par les [soreties
86+
d'ancrage][topic anchor outputs] de LN pour protéger une grande quantité d'argent dans les canaux de
87+
paiement. En combinaison avec [le relai par paquet][topic package relay] (spécifiquement le paquet
88+
Replace By Fee), le RBFR en une seule fois pourrait être capable de remplacer CPFP-CO sans
89+
nécessiter de changements dans aucun logiciel LN qui augmente déjà à plusieurs reprises les frais de
90+
ses dépenses de sortie d'ancrage par RBF. Cependant, le RBFR en une seule fois dépend de l'apprentissage
91+
des taux de frais du haut-mempool de quelque chose comme le cluster de mempool, donc à la fois RBFR et
92+
le cluster de mempool devraient être déployés simultanément ou une méthode alternative pour déterminer les
93+
taux de frais du haut-mempool devrait être utilisée.
94+
95+
En comparaison, TRUC fournit également une alternative à CPFP-CO, mais c'est une fonctionnalité
96+
facultative. Tout le logiciel LN devrait être mis à niveau pour supporter TRUC et tous les canaux
97+
existants devraient subir une [mise à niveau de l'engagement du canal][topic channel commitment
98+
upgrades]. Cela pourrait prendre un temps significatif et CPFP-CO ne pourrait pas être désactivé
99+
tant qu'il n'y aurait pas de preuves solides que tous les utilisateurs de LN ont été mis à niveau.
100+
Jusqu'à ce que CPFP-CO soit désactivé, le cluster de mempool ne pourrait pas être déployé en toute
101+
sécurité à grande échelle.
102+
103+
Comme mentionné dans les précédents bulletins Optech [#286][news286 imbued], [#287][news287
104+
sibling], et [#289][news289 imbued], une adoption lente de TRUC et une disponibilité rapide de
105+
cluster de mempool pourraient être abordées à travers _TRUC imbued_, qui appliquerait automatiquement
106+
TRUC et l'[éviction de frères et sœurs][topic kindred rbf] vers des transactions d'engagement de style ancrage LN.
107+
Plusieurs développeurs LN et contributeurs à la proposition TRUC imbued [ont dit][teinurier
108+
hacky] qu'ils préféreraient éviter ce résultat---mettre à jour explicitement vers TRUC est meilleur
109+
à bien des égards, et il y a plusieurs autres raisons pour les développeurs LN de travailler sur des
110+
mécanismes de mise à niveau de canal---mais il semble plausible que TRUC imbued puisse être
111+
considéré à nouveau si le développement du cluster de mempool devance celui des mises à niveau
112+
d'engagement LN.
113+
114+
Bien que TRUC imbued et l'adoption généralisée de TRUC opt-in permettent de désactiver CPFP-CO et
115+
rendent ainsi possible le déploiement de cluster de mempool, aucun système TRUC ne dépend de cluster
116+
de mempool ou d'autres nouvelles méthodes de calcul de la compatibilité des incitations
117+
transactionnelles. Cela facilite l'analyse de TRUC indépendamment de cluster de mempool que celle de
118+
RBFR.
119+
120+
À la date de rédaction de ce texte, la discussion sur la liste de diffusion est en cours.
121+
122+
## Questions et réponses sélectionnées de Bitcoin Stack Exchange
123+
124+
*[Bitcoin Stack Exchange][bitcoin.se] est l'un des premiers endroits où les contributeurs Optech
125+
cherchent des réponses à leurs questions---ou quand nous avons quelques moments libres pour aider
126+
les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en lumière certaines
127+
des questions et réponses les plus votées publiées depuis notre dernière mise à jour.*
128+
129+
{% comment %}<!-- https://bitcoin.stackexchange.com/search?tab=votes&q=created%3a1m..%20is%3aanswer -->{% endcomment %}
130+
{% assign bse = "https://bitcoin.stackexchange.com/a/" %}
131+
132+
- [Pourquoi est-il nécessaire de restructurer le mempool avec le cluster de mempool ?]({{bse}}123682)
133+
Murch explique les problèmes avec la structure actuelle du mempool de Bitcoin Core, comment le cluster
134+
de mempool aborde ces problèmes, et comment le [cluster de mempool][topic cluster mempool] peut être déployé
135+
dans Bitcoin Core.
136+
137+
- [Le DEFAULT_MAX_PEER_CONNECTIONS pour Bitcoin Core est de 125 ou 130 ?]({{bse}}123645)
138+
Lightlike clarifie que bien que le nombre maximum de connexions de pairs automatiques soit de 125
139+
dans Bitcoin Core, un opérateur de nœud peut ajouter jusqu'à 8 connexions supplémentaires
140+
manuellement.
141+
142+
- [Pourquoi les développeurs de protocole travaillent-ils à maximiser les revenus des mineurs ?]({{bse}}123679)
143+
David A. Harding liste plusieurs avantages à pouvoir prédire quelles transactions entrent dans un
144+
bloc en supposant que les mineurs maximiseront les revenus des frais, notant "Cela permet à ceux
145+
qui effectuent une dépense de faire des estimations de taux de frais raisonnables, aux nœuds de relais bénévoles de
146+
fonctionner avec une quantité modeste de bande passante et de mémoire, et aux petits mineurs
147+
décentralisés de gagner autant de revenus de frais que les grands mineurs".
148+
149+
- [Y a-t-il un incitatif économique à utiliser P2WSH plutôt que P2TR ?]({{bse}}123500)
150+
Vojtěch Strnad souligne que bien que certaines utilisations de P2WSH puissent être moins chères que
151+
les sorties P2TR, la plupart des cas d'utilisation de P2WSH, comme le multisig et LN,
152+
bénéficieraient des frais réduits permis par la dissimulation des chemins de script inutilisés dans
153+
[taproot][topic taproot] et l'utilisation de [signatures schnorr][topic schnorr signatures] pour
154+
systèmes de regroupement de clés comme [MuSig2][topic musig] et FROST.
155+
156+
- [Combien de blocs par seconde peuvent être créés de manière durable en utilisant une attaque par distorsion temporelle ?]({{bse}}123698)
157+
Murch calcule que dans le contexte d'une [attaque par distorsion temporelle][topic time warp],
158+
"Un attaquant serait capable de maintenir une cadence de 6 blocs par seconde sans
159+
augmenter la difficulté."
160+
161+
- [pkh() imbriqué dans tr() est-il autorisé ?]({{bse}}123568)
162+
Pieter Wuille souligne que, selon [BIP386][], "Descripteurs de Script de Sortie tr()",
163+
`pkh()` imbriqué dans `tr()` n'est pas un descripteur valide, mais que
164+
sous [BIP379][] "Miniscript" une telle construction est autorisée et qu'il appartient
165+
au développeur d'application de décider quels BIP spécifiques ils suivent.
166+
167+
- [Un bloc de plus d'une semaine peut-il être considéré comme une extrémité de chaîne valide ?]({{bse}}123671)
168+
Murch conclut qu'une telle extrémité de chaîne pourrait être considérée comme valide, mais que le
169+
nœud resterait dans l'état "initialblockdownload" tant que l"extrémité de chaîne est à plus de 24 heures
170+
dans le passé selon l'heure locale du nœud.
171+
172+
- [Modification de tx médiée par SIGHASH_ANYONECANPAY]({{bse}}123429)
173+
Murch explique les défis de l'utilisation de `SIGHASH_ALL | SIGHASH_ANYONECANPAY` dans
174+
un schéma de financement participatif on chain et comment [SIGHASH_ANYPREVOUT][topic
175+
sighash_anyprevout] pourrait aider.
176+
177+
- [Pourquoi la règle RBF n°3 existe-t-elle ?]({{bse}}123595)
178+
Antoine Poinsot confirme que la règle [RBF][topic rbf] n°4 (la transaction de remplacement paie des
179+
frais supplémentaires par rapport aux frais absolus de la transaction originale)
180+
est plus stricte que la règle n°3 (le remplacement paie des frais absolus d'au moins la somme
181+
payée par la transaction originale) et note que la raison de ces deux règles similaires dans la
182+
documentation vient des deux vérifications séparées dans le code.
183+
184+
## Mises à jour et versions candidates
185+
186+
*Nouvelles sorties et candidats à la sortie pour les projets d'infrastructure Bitcoin populaires.
187+
Veuillez envisager de passer aux nouvelles sorties ou d'aider à tester
188+
les candidats à la sortie.*
189+
190+
- [BDK 1.0.0-beta.1][] est un candidat à la sortie pour "la première version bêta de
191+
`bdk_wallet` avec une API stable 1.0.0".
192+
193+
## Changements notables de code et de documentation
194+
195+
_Changements récents notables dans [Bitcoin Core][bitcoin core repo], [Core
196+
Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo],
197+
[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Interface de Portefeuille Matériel (HWI)][hwi
198+
repo], [Rust Bitcoin][rust bitcoin repo], [Serveur BTCPay][btcpay server repo], [BDK][bdk repo],
199+
[Propositions d'Amélioration de Bitcoin (BIPs)][bips repo], [Lightning BOLTs][bolts repo],
200+
[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] et [BINANAs][binana
201+
repo]._
202+
203+
- [Bitcoin Core #30320][] met à jour le comportement [assumeUTXO][topic assumeutxo] pour éviter de
204+
charger un instantané s'il n'est pas un ascendant de l'en-tête actuel le plus à jour `m_best_header`
205+
et synchronise à la place comme un nœud régulier. Si l'instantané devient plus tard un ascendant de
206+
l'en-tête le plus à jour en raison d'une réorganisation de la chaîne, le chargement de l'instantané
207+
assumeUTXO reprend.
208+
209+
- [Bitcoin Core #29523][] ajoute une option `max_tx_weight` aux commandes RPC de financement de
210+
transaction `fundrawtransaction`, `walletcreatefundedpsbt` et `send`. Cela garantit que le poids de
211+
la transaction résultante ne dépasse pas la limite spécifiée, ce qui peut être bénéfique pour les
212+
tentatives futures de [RBF][topic rbf] ou pour des protocoles de transaction spécifiques. Si non
213+
défini, le `MAX_STANDARD_TX_WEIGHT` de 400 000 unités de poids (100 000 vbytes) est utilisé comme
214+
valeur par défaut.
215+
216+
- [Core Lightning #7461][] ajoute le support pour que les nœuds auto-récupèrent et auto-payent les
217+
[offres BOLT12][topic offers] et les factures, ce qui peut simplifier le code de gestion de compte
218+
qui appelle CLN en arrière-plan comme décrit dans le [Bulletin #262][cln self-pay]. Le PR permet
219+
également aux nœuds de payer une facture même si le nœud lui-même est la tête du [chemin
220+
aveuglé][topic rv routing]. De plus, les nœuds non annoncés (ceux sans [canaux non annoncés][topic
221+
unannounced channels]) peuvent maintenant créer des offres en ajoutant automatiquement un chemin
222+
aveuglé dont l'avant-dernier saut est l'un de leurs pairs de canal.
223+
224+
- [Eclair #2881][] supprime le support pour les nouveaux canaux entrants `static_remote_key`, tout
225+
en maintenant le support pour ceux existants et pour les nouveaux canaux sortants qui utilisent
226+
cette option. Les nœuds devraient utiliser les [sorties d'ancrage][topic anchor outputs] à la place, car
227+
les nouveaux canaux entrants `static_remote_key` sont désormais considérés comme obsolètes.
228+
229+
{% assign four_days_after_posting = page.date | date: "%s" | plus: 345600 | date: "%Y-%m-%d 14:30" %}
230+
{% include snippets/recap-ad.md when=four_days_after_posting %}
231+
{% include references.md %}
232+
{% include linkers/issues.md v=2 issues="30320,29523,7461,2881" %}
233+
{% include linkers/issues.md v=2 issues="30320,29523,7461,2881" %}
234+
[BDK 1.0.0-beta.1]: https://github.com/bitcoindevkit/bdk/releases/tag/v1.0.0-beta.1
235+
[news263 full-rbf]: /fr/newsletters/2023/08/09/#full-rbf-par-defaut
236+
[news288 rbfr]: /fr/newsletters/2024/02/07/#proposition-de-remplacement-par-feerate-pour-echapper-au-pinning
237+
[news283 truc pin]: /fr/newsletters/2024/01/03/#couts-d-epinglage-des-transactions-v3
238+
[news288 rbfr]: /fr/newsletters/2024/02/07/#proposition-de-remplacement-par-feerate-pour-echapper-au-pinning
239+
[news290 rbf]: /fr/newsletters/2024/02/21/#le-simple-remplacement-par-taux-de-frais-ne-garantit-pas-la-compatibilite-des-incitations
240+
[news285 cluster cpfp-co]: /fr/newsletters/2024/01/17/#la-suppression-du-decoupage-cpfp-est-necessaire
241+
[news286 imbued]: /fr/newsletters/2024/01/24/#logique-imbriquee-v3
242+
[news287 sibling]: /fr/newsletters/2024/01/31/#remplacement-par-frais-de-parente
243+
[news289 imbued]: /fr/newsletters/2024/02/14/#que-se-serait-il-passe-si-les-regles-v3-avaient-ete-appliquees-aux-sorties-d-ancrage-il-y-a-un-an
244+
[todd fr-rbf]: https://mailing-list.bitcoindevs.xyz/bitcoindev/[email protected]/
245+
[harding rbfr fundamental]: https://mailing-list.bitcoindevs.xyz/bitcoindev/[email protected]/
246+
[todd unsolvable]: https://mailing-list.bitcoindevs.xyz/bitcoindev/[email protected]/
247+
[teinurier hacky]: https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1968709925
248+
[daftuar prefer not]: https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1968709925
249+
[cln self-pay]: /fr/newsletters/2023/08/02/#core-lightning-6399

0 commit comments

Comments
 (0)