|
| 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