From 137f87c1420cfe1133f63024ebf3adff0dfb5acc Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Thu, 6 Jul 2023 18:38:03 +0200 Subject: [PATCH 01/15] Create 2023-06-28-newsletter.md --- .../fr/newsletters/2023-06-28-newsletter.md | 228 ++++++++++++++++++ 1 file changed, 228 insertions(+) create mode 100644 _posts/fr/newsletters/2023-06-28-newsletter.md diff --git a/_posts/fr/newsletters/2023-06-28-newsletter.md b/_posts/fr/newsletters/2023-06-28-newsletter.md new file mode 100644 index 000000000..a171f5d09 --- /dev/null +++ b/_posts/fr/newsletters/2023-06-28-newsletter.md @@ -0,0 +1,228 @@ +--- +title: 'Bulletin hebdomadaire Bitcoin Optech #257' +permalink: /fr/newsletters/2023/06/28/ +name: 2023-06-28-newsletter-fr +slug: 2023-06-28-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +This week's newsletter summarizes an idea for preventing the pinning of +coinjoin transactions and describes a proposal for speculatively using +hoped-for consensus changes. Also included is another entry in our +limited weekly series about mempool policy, plus our regular sections +describing popular questions and answers on the Bitcoin Stack Exchange, +new releases and release candidates, and changes to popular Bitcoin +infrastructure software. + +## News + +- **Preventing coinjoin pinning with v3 transaction relay:** Greg + Sanders [posted][sanders v3cj] to the Bitcoin-Dev mailing list a + description for how the proposed [v3 transaction relay rules][topic v3 + transaction relay] could allow creating a [coinjoin][topic + coinjoin]-style multiparty transaction that wouldn't be vulnerable to + [transaction pinning][topic transaction pinning]. The specific + concern with pinning is that one of the participants in a coinjoin can + use their input to the transaction to create a conflicting transaction + that prevents the coinjoin transaction from confirming. + + Sanders proposes that coinjoin-style transactions can avoid this + problem by having each participant initially spend their bitcoins to + a script that can only be spent by either a signature from all + participants in the coinjoin or by just the participant after a + timelock expires. Alternatively, for a coordinated coinjoin, the + coordinator and the participant must sign together (or the + participant alone after the timelock expiration). + + Up until the timelock expires, the participant must now get either + the other parties or the coordinator to co-sign any conflicting + transactions, which they are unlikely to do unless signing would be + in the best interests of all the participants (e.g. a [fee + bump][topic rbf]). {% assign timestamp="16:08" %} + +- **Speculatively using hoped-for consensus changes:** Robin Linus + [posted][linus spec] to the Bitcoin-Dev mailing list an idea for + spending money to a script fragment that can't be executed for a long + time (such as 20 years). If that script fragment is interpreted under + current consensus rules, it will allow miners in 20 years to claim all + the funds paid to it. However, the fragment is designed so that an + upgrade to the consensus rules will give the fragment a different + meaning. Linus gives the example of an `OP_ZKP_VERIFY` opcode that, + if added to Bitcoin, will allow anyone providing a Zero-Knowledge + Proof (ZKP) for a program with a particular hash to claim the funds. + + This could allow people to spend BTC today to one of these scripts + and use the proof of that spend to receive an equivalent amount of + BTC on a [sidechain][topic sidechains] or alternative chain, called a + _one-way peg_. The BTC on the other chain could be spent repeatedly + for 20 years, until the script timelock expired. Then the current + owner of the BTC on the other chain could generate a ZKP proof that + they owned it and use that proof to withdraw the locked deposit on + the Bitcoin mainnet, creating a _two-way peg_. With a good design + for the verification program, the withdrawal would be simple and + flexible, which would allow for fungible withdrawals. + + The authors note that anyone who would benefit from this + construction (e.g. who receives BTC on another chain) is basically + making a bet that Bitcoin's consensus rules will be changed (e.g. + `OP_ZKP_VERIFY` will be added). This gives them an incentive to + advocate for the change, but heavily incentivizing some users to + change the system may result in other users feeling like they're + being coerced. The idea had not received any discussion on the + mailing list as of this writing. {% assign timestamp="1:33" %} + +## Waiting for confirmation #7: Network Resources + +_A limited weekly [series][policy series] about transaction relay, +mempool inclusion, and mining transaction selection---including why +Bitcoin Core has a more restrictive policy than allowed by consensus and +how wallets can use that policy most effectively._ + +{% include specials/policy/en/07-network-resources.md %} {% assign timestamp="24:46" %} + +## Selected Q&A from Bitcoin Stack Exchange + +*[Bitcoin Stack Exchange][bitcoin.se] is one of the first places Optech +contributors look for answers to their questions---or when we have a +few spare moments to help curious or confused users. In +this monthly feature, we highlight some of the top-voted questions and +answers posted since our last update.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Why do Bitcoin nodes accept blocks that have so many excluded transactions?]({{bse}}118707) + User commstark wonders why a node accepts a block from miners that exclude + transactions that were anticipated for that block according to that node's + [block template][reference getblocktemplate]. There are various [tools][miningpool observer] that + [show][mempool space] expected compared to actual blocks. Pieter Wuille points + out that due to inherent variance in different nodes' [mempools][waiting for + confirmation 1] related to transaction propagation, a consensus rule enforcing + block contents is not possible. {% assign timestamp="57:38" %} + +- [Why does everyone say that soft forks restrict the existing ruleset?]({{bse}}118642) + Pieter Wuille uses the rules added during the [taproot][topic taproot] and + [segwit][topic segwit] soft fork [activations][topic soft fork activation] as + examples of tightening the consensus rules: + + - taproot added the requirement that `OP_1 <32 bytes>` (taproot) output spends + adhere to the taproot consensus rules + - segwit added the requirement that `OP_{0..16} <2..40 bytes>` (segwit) output + spends adhere to the segwit consensus rules and also requires empty witness + data for pre-segwit outputs {% assign timestamp="1:05:28" %} + +- [Why is the default LN channel limit set to 16777215 sats?]({{bse}}118709) + Vojtěch Strnad explains the 2^24 satoshi limit history and motivation for + large (wumbo) channels and also links to Optech's [large channel topic][topic + large channels] for more information. {% assign timestamp="1:07:47" %} + +- [Why does Bitcoin Core use ancestor score instead of just ancestor fee rate to select transactions?]({{bse}}118611) + Sdaftuar explains that performance optimization is the reason that the mining + block template transaction selection algorithm uses both the ancestor feerate and ancestor + score. (See [Waiting for confirmation #2: Incentives][waiting for confirmation + 2]). {% assign timestamp="1:10:28" %} + +- [How does Lightning multipart payments (MPP) protocol define the amounts per part?]({{bse}}117405) + Rene Pickhardt points out that [multipath payments][topic multipath payments] + do not have a protocol-specified part size or algorithm for choosing part size and + points out some relevant payment-splitting research. {% assign timestamp="1:14:15" %} + +## Releases and release candidates + +*New releases and release candidates for popular Bitcoin infrastructure +projects. Please consider upgrading to new releases or helping to test +release candidates.* + +- [BTCPay Server 1.10.3][] is the latest release for this self-hosted + payment processing software. See their [blog post][btcpay 1.10] for a + tour of the headline features in the 1.10 branch. {% assign timestamp="1:16:08" %} + +## Notable code and documentation changes + +*Notable changes this week in [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], and +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Core Lightning #6303][] adds a new `setconfig` RPC that allows + changing some configuration options without restarting the daemon. {% assign timestamp="1:21:14" %} + +- [Eclair #2701][] begins recording both when an offered [HTLC][topic + htlc] is received and when it is settled. This allows tracking how + long the HTLC was pending from the node's perspective. If many HTLCs, + or a few high-value HTLCs, are pending for long periods of time, this + may indicate a [channel jamming attack][topic channel jamming attacks] + is in progress. Tracking HTLC duration helps detect such attacks and + may contribute to mitigating them. {% assign timestamp="1:22:21" %} + +- [Eclair #2696][] changes how Eclair allows users to configure what + feerates to use. Previously, users could specify what feerate to use + with a _block target_, e.g. a setting of "6" meant Eclair would try to + get a transaction confirmed within six blocks. Now Eclair accepts + "slow", "medium", and "fast", which it translates into specific + feerates using constants or block targets. {% assign timestamp="1:25:03" %} + +- [LND #7710][] adds the ability for plugins (or the daemon itself) to + retrieve data received earlier in an HTLC. This is necessary for + [route blinding][topic rv routing] and may be used by various [channel + jamming][topic channel jamming attacks] countermeasures, among other + ideas for future features. {% assign timestamp="1:26:51" %} + +- [LDK #2368][] allows accepting new channels created by a peer that use + [anchor outputs][topic anchor outputs] but requires the controlling + program deliberately choose to accept each new channel. This is done + because properly settling an anchor channel may require the user to have + access to one or more UTXOs with sufficient value. LDK, as a library + that is unaware of what non-LN UTXOs the user's wallet controls, uses + this prompt to give the controlling program a chance to verify that it + has the necessary UTXOs. {% assign timestamp="1:27:43" %} + +- [LDK #2367][] makes [anchor channels][topic anchor outputs] accessible + to regular consumers of the API. {% assign timestamp="1:33:34" %} + +- [LDK #2319][] allows a peer to create an HTLC that commits to paying + less than the amount the original spender said should be paid, + allowing the peer to keep the difference for itself as an extra fee. This + is useful for the creation of [JIT channels][topic jit channels] where + a peer receives an HTLC for a receiver that doesn't have a channel + yet. The peer creates an onchain transaction that funds the channel + and commits to the HTLC within that channel---but it incurs additional + transaction fees in creating that onchain transaction. By taking an + extra fee, it is compensated for its costs if the receiver accepts the + new channel and settles the HTLC on time. {% assign timestamp="1:34:40" %} + +- [LDK #2120][] adds support for finding a route to a receiver who is + using [blinded paths][topic rv routing]. {% assign timestamp="1:37:09" %} + +- [LDK #2089][] adds an event handler that makes it easy for wallets to + fee bump any [HTLCs][topic htlc] that need to be settled onchain. {% assign timestamp="1:38:12" %} + +- [LDK #2077][] refactors a large amount of code to make it easier later + to add support for [dual funded channels][topic dual funding]. {% assign timestamp="1:39:08" %} + +- [Libsecp256k1 #1129][] implements the [ElligatorSwift][ElligatorSwift paper] + technique to introduce a 64-byte public key encoding that is computationally + indistinguishable from random data. The `ellswift` module provides functions + for encoding and decoding public keys in the new format as well as + convenience functions to generate new uniformly-random keys and perform + an Elliptic Curve Diffie-Hellman key exchange (ECDH) on ellswift-encoded + keys. The ellswift-based ECDH is to be used in establishing connections + for the [version 2 P2P encrypted transport][topic v2 p2p transport] protocol ([BIP324][]). {% assign timestamp="1:40:37" %} + +{% include references.md %} +{% include linkers/issues.md v=2 issues="6303,2701,2696,7710,2368,2367,2319,2120,2089,2077,1129" %} +[policy series]: /en/blog/waiting-for-confirmation/ +[sanders v3cj]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021780.html +[linus spec]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021781.html +[BTCPay Server 1.10.3]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.10.3 +[btcpay 1.10]: https://blog.btcpayserver.org/btcpay-server-1-10-0/ +[miningpool observer]: https://miningpool.observer/template-and-block +[mempool space]: https://mempool.space/graphs/mining/block-health +[waiting for confirmation 1]: /en/blog/waiting-for-confirmation/#why-do-we-have-a-mempool +[reference getblocktemplate]: https://developer.bitcoin.org/reference/rpc/getblocktemplate.html +[waiting for confirmation 2]: /en/blog/waiting-for-confirmation/#incentives +[ElligatorSwift paper]: https://eprint.iacr.org/2022/759 From ca7a8ece3819fa9248e0ee916c7c56661b4ec1e2 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sun, 9 Jul 2023 17:48:07 +0200 Subject: [PATCH 02/15] Update 2023-06-28-newsletter.md --- .../fr/newsletters/2023-06-28-newsletter.md | 319 +++++++++--------- 1 file changed, 160 insertions(+), 159 deletions(-) diff --git a/_posts/fr/newsletters/2023-06-28-newsletter.md b/_posts/fr/newsletters/2023-06-28-newsletter.md index a171f5d09..09f0e1f3f 100644 --- a/_posts/fr/newsletters/2023-06-28-newsletter.md +++ b/_posts/fr/newsletters/2023-06-28-newsletter.md @@ -7,179 +7,180 @@ type: newsletter layout: newsletter lang: fr --- -This week's newsletter summarizes an idea for preventing the pinning of -coinjoin transactions and describes a proposal for speculatively using -hoped-for consensus changes. Also included is another entry in our -limited weekly series about mempool policy, plus our regular sections -describing popular questions and answers on the Bitcoin Stack Exchange, -new releases and release candidates, and changes to popular Bitcoin -infrastructure software. - -## News - -- **Preventing coinjoin pinning with v3 transaction relay:** Greg - Sanders [posted][sanders v3cj] to the Bitcoin-Dev mailing list a - description for how the proposed [v3 transaction relay rules][topic v3 - transaction relay] could allow creating a [coinjoin][topic - coinjoin]-style multiparty transaction that wouldn't be vulnerable to - [transaction pinning][topic transaction pinning]. The specific - concern with pinning is that one of the participants in a coinjoin can - use their input to the transaction to create a conflicting transaction - that prevents the coinjoin transaction from confirming. - - Sanders proposes that coinjoin-style transactions can avoid this - problem by having each participant initially spend their bitcoins to - a script that can only be spent by either a signature from all - participants in the coinjoin or by just the participant after a - timelock expires. Alternatively, for a coordinated coinjoin, the - coordinator and the participant must sign together (or the - participant alone after the timelock expiration). - - Up until the timelock expires, the participant must now get either - the other parties or the coordinator to co-sign any conflicting - transactions, which they are unlikely to do unless signing would be - in the best interests of all the participants (e.g. a [fee - bump][topic rbf]). {% assign timestamp="16:08" %} - -- **Speculatively using hoped-for consensus changes:** Robin Linus - [posted][linus spec] to the Bitcoin-Dev mailing list an idea for - spending money to a script fragment that can't be executed for a long - time (such as 20 years). If that script fragment is interpreted under - current consensus rules, it will allow miners in 20 years to claim all - the funds paid to it. However, the fragment is designed so that an - upgrade to the consensus rules will give the fragment a different - meaning. Linus gives the example of an `OP_ZKP_VERIFY` opcode that, - if added to Bitcoin, will allow anyone providing a Zero-Knowledge - Proof (ZKP) for a program with a particular hash to claim the funds. - - This could allow people to spend BTC today to one of these scripts - and use the proof of that spend to receive an equivalent amount of - BTC on a [sidechain][topic sidechains] or alternative chain, called a - _one-way peg_. The BTC on the other chain could be spent repeatedly - for 20 years, until the script timelock expired. Then the current - owner of the BTC on the other chain could generate a ZKP proof that - they owned it and use that proof to withdraw the locked deposit on - the Bitcoin mainnet, creating a _two-way peg_. With a good design - for the verification program, the withdrawal would be simple and - flexible, which would allow for fungible withdrawals. - - The authors note that anyone who would benefit from this - construction (e.g. who receives BTC on another chain) is basically - making a bet that Bitcoin's consensus rules will be changed (e.g. - `OP_ZKP_VERIFY` will be added). This gives them an incentive to - advocate for the change, but heavily incentivizing some users to - change the system may result in other users feeling like they're - being coerced. The idea had not received any discussion on the - mailing list as of this writing. {% assign timestamp="1:33" %} - -## Waiting for confirmation #7: Network Resources - -_A limited weekly [series][policy series] about transaction relay, -mempool inclusion, and mining transaction selection---including why -Bitcoin Core has a more restrictive policy than allowed by consensus and -how wallets can use that policy most effectively._ +Le bulletin de cette semaine résume une idée pour empêcher l'épinglage des +transactions coinjoin et décrit une proposition pour utiliser de manière +spéculative les changements de consensus espérés. Vous y trouverez également +une nouvelle contribution à notre série hebdomadaire limitée sur la politique +de mempool, ainsi que nos sections régulières concernant les questions et +réponses populaires sur le Bitcoin Stack Exchange, les nouvelles versions et +les versions candidates, et les changements apportés aux principaux logiciels +de l'infrastructure Bitcoin. + +## Nouvelles + +- **Prévenir l'épinglage des coinjoin avec le relais de transaction v3 :** Greg + Sanders a [posté][sanders v3cj] sur la liste de diffusion Bitcoin-Dev une + description de la manière dont les [règles de relais de transaction v3][topic v3 transaction relay] + proposées pourraient permettre de créer une transaction multipartite de type + [coinjoin][topic coinjoin] qui ne serait pas vulnérable à l'[épinglage de transaction][topic transaction pinning]. + Le problème spécifique de l'épinglage est que l'un des participants à une coinjoin + peut utiliser sa contribution à la transaction pour créer une transaction conflictuelle + qui empêche la transaction coinjoin de se confirmer. + + Sanders propose que les transactions de type coinjoin puissent éviter + ce problème en demandant à chaque participant de dépenser initialement + ses bitcoins dans un script qui ne peut être dépensé que par une signature + de tous les participants au coinjoin ou par le seul participant après + l'expiration d'un timelock. Par ailleurs, dans le cas d'un coinjoin coordonné, + le coordinateur et le participant doivent signer ensemble (ou le participant + seul après l'expiration du timelock). + + Jusqu'à l'expiration du délai, le participant doit maintenant obtenir + des autres parties ou du coordinateur qu'ils cosignent toute transaction + conflictuelle, ce qu'ils ne feront probablement pas, à moins que la + signature ne soit dans l'intérêt de tous les participants (par exemple, + un [fee bump][topic rbf]). {% assign timestamp="16:08" %} + +- **Spéculer en utilisant les changements de consensus espérés :** Robin Linus + a [posté][linus spec] sur la liste de diffusion Bitcoin-Dev une idée pour + dépenser de l'argent dans un fragment de script qui ne peut pas être exécuté + pendant une longue période (par exemple 20 ans). Si ce fragment de script est + interprété selon les règles actuelles de consensus, il permettra aux mineurs + dans 20 ans de réclamer tous les fonds qui lui ont été versés. Toutefois, le + fragment est conçu de manière à ce qu'une mise à jour des règles de consensus + lui donne une signification différente. Linus donne l'exemple d'un opcode + `OP_ZKP_VERIFY` qui, s'il est ajouté à Bitcoin, permettra à toute personne + fournissant une preuve de zéro connaissance (ZKP) pour un programme avec un + hachage particulier de réclamer les fonds. + + Cela pourrait permettre aux gens de dépenser aujourd'hui des BTC dans + l'un de ces scripts et d'utiliser la preuve de cette dépense pour recevoir + un montant équivalent de BTC sur une [sidechain][topic sidechains] ou une + chaîne alternative, appelée _one-way peg_. Les BTC sur l'autre chaîne peuvent + être dépensés de manière répétée pendant 20 ans, jusqu'à ce que le timelock + du script expire. Ensuite, le propriétaire actuel des BTC sur l'autre chaîne + pourrait générer une preuve ZKP qu'il les possède et utiliser cette preuve + pour retirer le dépôt bloqué sur le réseau principal de Bitcoin, créant ainsi + un _two-way peg_. Avec une bonne conception du programme de vérification, le + retrait serait simple et flexible, ce qui permettrait des retraits fongibles. + + Les auteurs notent que toute personne qui bénéficierait de cette construction + (par exemple, qui reçoit des BTC sur une autre chaîne) fait en fait le pari que + les règles de consensus de Bitcoin seront modifiées (par exemple, `OP_ZKP_VERIFY` + sera ajouté). Cela les incite à plaider en faveur du changement, mais en incitant + fortement certains utilisateurs à changer le système, d'autres utilisateurs pourraient + avoir l'impression d'être contraints. L'idée n'a fait l'objet d'aucune discussion + sur la liste de diffusion au moment de la rédaction de ce document. {% assign timestamp="1:33" %} + +## En attente de confirmation #7 : Ressources du réseau + +_Une [série][policy series] hebdomadaire limitée sur le relais de transaction, +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 permise par le +consensus et comment les portefeuilles peuvent utiliser cette politique de la +manière la plus efficace._ {% include specials/policy/en/07-network-resources.md %} {% assign timestamp="24:46" %} -## Selected Q&A from Bitcoin Stack Exchange +## Sélection de Q&R du Bitcoin Stack Exchange -*[Bitcoin Stack Exchange][bitcoin.se] is one of the first places Optech -contributors look for answers to their questions---or when we have a -few spare moments to help curious or confused users. In -this monthly feature, we highlight some of the top-voted questions and -answers posted since our last update.* +*[Bitcoin Stack Exchange][bitcoin.se] est l'un des premiers endroits où les contributeurs +d'Optech cherchent des réponses à leurs questions---ou lorsque nous avons quelques moments +libres pour aider les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous +mettons en avant certaines des questions et réponses les plus appréciées, postées depuis +notre dernière mise à jour.* {% comment %}{% endcomment %} {% assign bse = "https://bitcoin.stackexchange.com/a/" %} -- [Why do Bitcoin nodes accept blocks that have so many excluded transactions?]({{bse}}118707) - User commstark wonders why a node accepts a block from miners that exclude - transactions that were anticipated for that block according to that node's - [block template][reference getblocktemplate]. There are various [tools][miningpool observer] that - [show][mempool space] expected compared to actual blocks. Pieter Wuille points - out that due to inherent variance in different nodes' [mempools][waiting for - confirmation 1] related to transaction propagation, a consensus rule enforcing - block contents is not possible. {% assign timestamp="57:38" %} - -- [Why does everyone say that soft forks restrict the existing ruleset?]({{bse}}118642) - Pieter Wuille uses the rules added during the [taproot][topic taproot] and - [segwit][topic segwit] soft fork [activations][topic soft fork activation] as - examples of tightening the consensus rules: - - - taproot added the requirement that `OP_1 <32 bytes>` (taproot) output spends - adhere to the taproot consensus rules - - segwit added the requirement that `OP_{0..16} <2..40 bytes>` (segwit) output - spends adhere to the segwit consensus rules and also requires empty witness - data for pre-segwit outputs {% assign timestamp="1:05:28" %} - -- [Why is the default LN channel limit set to 16777215 sats?]({{bse}}118709) - Vojtěch Strnad explains the 2^24 satoshi limit history and motivation for - large (wumbo) channels and also links to Optech's [large channel topic][topic - large channels] for more information. {% assign timestamp="1:07:47" %} - -- [Why does Bitcoin Core use ancestor score instead of just ancestor fee rate to select transactions?]({{bse}}118611) - Sdaftuar explains that performance optimization is the reason that the mining - block template transaction selection algorithm uses both the ancestor feerate and ancestor - score. (See [Waiting for confirmation #2: Incentives][waiting for confirmation - 2]). {% assign timestamp="1:10:28" %} - -- [How does Lightning multipart payments (MPP) protocol define the amounts per part?]({{bse}}117405) - Rene Pickhardt points out that [multipath payments][topic multipath payments] - do not have a protocol-specified part size or algorithm for choosing part size and - points out some relevant payment-splitting research. {% assign timestamp="1:14:15" %} - -## Releases and release candidates - -*New releases and release candidates for popular Bitcoin infrastructure -projects. Please consider upgrading to new releases or helping to test -release candidates.* - -- [BTCPay Server 1.10.3][] is the latest release for this self-hosted - payment processing software. See their [blog post][btcpay 1.10] for a - tour of the headline features in the 1.10 branch. {% assign timestamp="1:16:08" %} - -## Notable code and documentation changes - -*Notable changes this week in [Bitcoin Core][bitcoin core repo], [Core +- [Pourquoi les nœuds Bitcoin acceptent-ils des blocs contenant autant de transactions exclues ?]({{bse}}118707) + L'utilisateur commstark se demande pourquoi un nœud accepte un bloc de mineurs + qui exclut les transactions prévues pour ce bloc selon le [modèle de bloc][reference getblocktemplate] + de ce nœud. Il existe divers [outils][miningpool observer] qui [montrent][mempool space] + les blocs prévus par rapport aux blocs réels. Pieter Wuille souligne qu'en raison de la + variance inhérente aux [mempools][waiting for confirmation 1] des différents nœuds liée + à la propagation des transactions, il n'est pas possible d'établir une règle de consensus + imposant le contenu des blocs. {% assign timestamp="57:38" %} + +- [Pourquoi tout le monde prétend-il que les fourches souples restreignent l'ensemble des règles existantes ?]({{bse}}118642) + Pieter Wuille utilise les règles ajoutées lors des [activations][topic soft fork activation] + des soft fork [taproot][topic taproot] et [segwit][topic segwit] comme exemples + de renforcement des règles de consensus : + + - taproot a ajouté l'exigence que les dépenses de sortie `OP_1 <32 bytes>` (taproot) + adhèrent aux règles de consensus de taproot. + - segwit a ajouté l'exigence que `OP_{0..16} <2..40 bytes>` (segwit) adhèrent aux + règles de consensus segwit et exigent également des données témoins vides pour + les sorties pré-segwit. {% assign timestamp="1:05:28" %} + +- [Pourquoi la limite par défaut du canal LN est-elle fixée à 16777215 sats ?]({{bse}}118709) + Vojtěch Strnad explique l'histoire de la limite de 2^24 satoshi et la motivation + pour les grands canaux (wumbo). Il renvoie également au [thème des grands canaux][topic large channels] + d'Optech pour plus d'informations. {% assign timestamp="1:07:47" %} + +- [Pourquoi Bitcoin Core utilise-t-il le score de l'ancêtre au lieu du taux de frais de l'ancêtre pour sélectionner les transactions ?]({{bse}}118611) + Sdaftuar explique que l'optimisation des performances est la raison pour laquelle + l'algorithme de sélection des transactions du modèle de bloc minier utilise à la fois + le taux de frais d'ancêtres et le score d'ancêtres. (Voir + [En attente de confirmation n° 2 : Incitations][waiting for confirmation 2]). {% assign timestamp="1:10:28" %} + +- [Comment le protocole Lightning multipart payments (MPP) définit-il les montants par part ?]({{bse}}117405) + Rene Pickhardt souligne que [les paiements par trajets multiples][topic multipath payments] + n'ont pas de taille de part spécifiée par le protocole ou d'algorithme pour choisir la taille + de la part et indique quelques recherches pertinentes sur le fractionnement des paiements. {% assign timestamp="1:14:15" %} + +## Mises à jour et versions candidates + +*Nouvelles versions et versions candidates pour les principaux projets d’infrastructure Bitcoin. + Veuillez envisager de passer aux nouvelles versions ou d’aider à tester les versions candidates.* + +- [BTCPay Server 1.10.3][] est la dernière version de ce logiciel de traitement de paiement + auto-hébergé. Consultez leur [billet de blog][btcpay 1.10] pour une visite des principales + fonctionnalités de la branche 1.10. {% assign timestamp="1:16:08" %} + +## 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], [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], and +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], et [Bitcoin Inquisition][bitcoin inquisition repo].* -- [Core Lightning #6303][] adds a new `setconfig` RPC that allows - changing some configuration options without restarting the daemon. {% assign timestamp="1:21:14" %} - -- [Eclair #2701][] begins recording both when an offered [HTLC][topic - htlc] is received and when it is settled. This allows tracking how - long the HTLC was pending from the node's perspective. If many HTLCs, - or a few high-value HTLCs, are pending for long periods of time, this - may indicate a [channel jamming attack][topic channel jamming attacks] - is in progress. Tracking HTLC duration helps detect such attacks and - may contribute to mitigating them. {% assign timestamp="1:22:21" %} - -- [Eclair #2696][] changes how Eclair allows users to configure what - feerates to use. Previously, users could specify what feerate to use - with a _block target_, e.g. a setting of "6" meant Eclair would try to - get a transaction confirmed within six blocks. Now Eclair accepts - "slow", "medium", and "fast", which it translates into specific - feerates using constants or block targets. {% assign timestamp="1:25:03" %} - -- [LND #7710][] adds the ability for plugins (or the daemon itself) to - retrieve data received earlier in an HTLC. This is necessary for - [route blinding][topic rv routing] and may be used by various [channel - jamming][topic channel jamming attacks] countermeasures, among other - ideas for future features. {% assign timestamp="1:26:51" %} - -- [LDK #2368][] allows accepting new channels created by a peer that use - [anchor outputs][topic anchor outputs] but requires the controlling - program deliberately choose to accept each new channel. This is done - because properly settling an anchor channel may require the user to have - access to one or more UTXOs with sufficient value. LDK, as a library - that is unaware of what non-LN UTXOs the user's wallet controls, uses - this prompt to give the controlling program a chance to verify that it - has the necessary UTXOs. {% assign timestamp="1:27:43" %} +- [Core Lightning #6303][] ajoute une nouvelle RPC `setconfig` qui permet + de changer certaines options de configuration sans redémarrer le démon. {% assign timestamp="1:21:14" %} + +- [Eclair #2701][] commence l'enregistrement à la fois au moment où un + [HTLC][topic htlc] offert est reçu et au moment où il est réglé. Cela + permet de savoir combien de temps le HTLC a été en attente du point de + vue du nœud. Si de nombreux HTLC, ou quelques HTLC de grande valeur, + sont en attente pendant de longues périodes, cela peut indiquer qu'une + [attaque par brouillage de canal][topic channel jamming attacks] est en + cours. Le suivi de la durée des HTLC permet de détecter de telles attaques + et peut contribuer à les atténuer. {% assign timestamp="1:22:21" %} + +- [Eclair #2696][] modifie la façon dont Eclair permet aux utilisateurs de + configurer les taux de frais à utiliser. Auparavant, les utilisateurs pouvaient + spécifier la vitesse à utiliser avec un _block target_, par exemple, un + réglage de "6" signifiait qu'Eclair essaierait de faire confirmer une + transaction dans un délai de six blocs. Désormais, Eclair accepte les + termes "lent", "moyen" et "rapide", qu'il traduit en taux de frais spécifiques + à l'aide de constantes ou de cibles de blocs. {% assign timestamp="1:25:03" %} + +- [LND #7710][] ajoute la possibilité pour les plugins (ou le démon lui-même) + de récupérer les données reçues plus tôt dans un HTLC. Ceci est nécessaire pour + le [route aveugle][topic rv routing] et peut être utilisé par diverses contre-mesures + de [brouillage de canal][topic channel jamming attacks], parmi d'autres idées + pour de futures fonctionnalités. {% assign timestamp="1:26:51" %} + +- [LDK #2368][] permet d'accepter de nouveaux canaux créés par un pair qui utilise + des [sorties d'ancrage][stopic anchor outputs] mais exige que le programme de contrôle + choisisse délibérément d'accepter chaque nouveau canal. En effet, pour régler correctement + un canal d'ancrage, l'utilisateur doit avoir accès à un ou plusieurs UTXO de valeur suffisante. + LDK, en tant que bibliothèque ignorant quels UTXOs non-LN le portefeuille de l'utilisateur + contrôle, utilise cette requête pour donner au programme de contrôle une chance de vérifier + qu'il a les UTXOs nécessaires. {% assign timestamp="1:27:43" %} - [LDK #2367][] makes [anchor channels][topic anchor outputs] accessible to regular consumers of the API. {% assign timestamp="1:33:34" %} From 38ff411a3b416ad850b60b33b4434b2484b6ddf4 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 10 Jul 2023 08:16:29 +0200 Subject: [PATCH 03/15] Update 2023-06-28-newsletter.md --- _posts/fr/newsletters/2023-06-28-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/fr/newsletters/2023-06-28-newsletter.md b/_posts/fr/newsletters/2023-06-28-newsletter.md index 09f0e1f3f..8c1d812b3 100644 --- a/_posts/fr/newsletters/2023-06-28-newsletter.md +++ b/_posts/fr/newsletters/2023-06-28-newsletter.md @@ -175,7 +175,7 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], et pour de futures fonctionnalités. {% assign timestamp="1:26:51" %} - [LDK #2368][] permet d'accepter de nouveaux canaux créés par un pair qui utilise - des [sorties d'ancrage][stopic anchor outputs] mais exige que le programme de contrôle + des [sorties d'ancrage][topic anchor outputs] mais exige que le programme de contrôle choisisse délibérément d'accepter chaque nouveau canal. En effet, pour régler correctement un canal d'ancrage, l'utilisateur doit avoir accès à un ou plusieurs UTXO de valeur suffisante. LDK, en tant que bibliothèque ignorant quels UTXOs non-LN le portefeuille de l'utilisateur From 765916bf96dc8bda75b77383398758cc396339ec Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 10 Jul 2023 08:48:18 +0200 Subject: [PATCH 04/15] Update 2023-06-28-newsletter.md --- .../fr/newsletters/2023-06-28-newsletter.md | 63 +++++++++---------- 1 file changed, 30 insertions(+), 33 deletions(-) diff --git a/_posts/fr/newsletters/2023-06-28-newsletter.md b/_posts/fr/newsletters/2023-06-28-newsletter.md index 8c1d812b3..49bfae31c 100644 --- a/_posts/fr/newsletters/2023-06-28-newsletter.md +++ b/_posts/fr/newsletters/2023-06-28-newsletter.md @@ -182,37 +182,34 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], et contrôle, utilise cette requête pour donner au programme de contrôle une chance de vérifier qu'il a les UTXOs nécessaires. {% assign timestamp="1:27:43" %} -- [LDK #2367][] makes [anchor channels][topic anchor outputs] accessible - to regular consumers of the API. {% assign timestamp="1:33:34" %} - -- [LDK #2319][] allows a peer to create an HTLC that commits to paying - less than the amount the original spender said should be paid, - allowing the peer to keep the difference for itself as an extra fee. This - is useful for the creation of [JIT channels][topic jit channels] where - a peer receives an HTLC for a receiver that doesn't have a channel - yet. The peer creates an onchain transaction that funds the channel - and commits to the HTLC within that channel---but it incurs additional - transaction fees in creating that onchain transaction. By taking an - extra fee, it is compensated for its costs if the receiver accepts the - new channel and settles the HTLC on time. {% assign timestamp="1:34:40" %} - -- [LDK #2120][] adds support for finding a route to a receiver who is - using [blinded paths][topic rv routing]. {% assign timestamp="1:37:09" %} - -- [LDK #2089][] adds an event handler that makes it easy for wallets to - fee bump any [HTLCs][topic htlc] that need to be settled onchain. {% assign timestamp="1:38:12" %} - -- [LDK #2077][] refactors a large amount of code to make it easier later - to add support for [dual funded channels][topic dual funding]. {% assign timestamp="1:39:08" %} - -- [Libsecp256k1 #1129][] implements the [ElligatorSwift][ElligatorSwift paper] - technique to introduce a 64-byte public key encoding that is computationally - indistinguishable from random data. The `ellswift` module provides functions - for encoding and decoding public keys in the new format as well as - convenience functions to generate new uniformly-random keys and perform - an Elliptic Curve Diffie-Hellman key exchange (ECDH) on ellswift-encoded - keys. The ellswift-based ECDH is to be used in establishing connections - for the [version 2 P2P encrypted transport][topic v2 p2p transport] protocol ([BIP324][]). {% assign timestamp="1:40:37" %} +- [LDK #2367][] rend les [canaux d'ancrage][topic anchor outputs] accessibles aux consommateurs + réguliers de l'API. {% assign timestamp="1:33:34" %} + +- [LDK #2319][] permet à un pair de créer un HTLC qui s'engage à payer moins que le montant que + le contributeur original a dit devoir être payé, ce qui permet au pair de garder la différence + pour lui-même en tant que frais supplémentaires. Ceci est utile pour la création de [JIT channels][topic jit channels] + où un pair reçoit un HTLC pour un destinataire qui n'a pas encore de canal. Le pair crée une + transaction onchain qui finance le canal et s'engage dans le HTLC au sein de ce canal---mais + il encourt des frais de transaction supplémentaires en créant cette transaction onchain. En prenant + des frais supplémentaires, il est compensé pour ses coûts si le destinataire accepte le nouveau canal + et règle le HTLC à temps. {% assign timestamp="1:34:40" %} + +- [LDK #2120][] ajoute la prise en charge de la recherche d'un itinéraire vers un destinataire + qui utilise des [chemins aveugles][topic rv routing]. {% assign timestamp="1:37:09" %} + +- [LDK #2089][] ajoute un gestionnaire d'événement qui permet aux portefeuilles de déclencher + facilement les [HTLC][topic htlc] qui doivent être réglés onchain. {% assign timestamp="1:38:12" %} + +- [LDK #2077][] remanie une grande partie du code pour faciliter l'ajout ultérieur de la prise + en charge des [canaux à double financement][topic dual funding]. {% assign timestamp="1:39:08" %} + +- [Libsecp256k1 #1129][] implémente la technique [ElligatorSwift][ElligatorSwift paper] pour introduire + un encodage de clé publique de 64 octets qui est informatiquement indiscernable des données aléatoires. + Le module `ellswift` fournit des fonctions pour encoder et décoder les clés publiques dans le nouveau + format ainsi que des fonctions de commodité pour générer de nouvelles clés uniformément aléatoires et + effectuer un échange de clés Diffie-Hellman à courbe elliptique (ECDH) sur les clés encodées ellswift. + L'ECDH basé sur ellswift doit être utilisé pour établir des connexions pour le protocole [transport P2P + chiffré version 2] [topic v2 p2p transport] ([BIP324][]). {% assign timestamp="1:40:37" %} {% include references.md %} {% include linkers/issues.md v=2 issues="6303,2701,2696,7710,2368,2367,2319,2120,2089,2077,1129" %} @@ -223,7 +220,7 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], et [btcpay 1.10]: https://blog.btcpayserver.org/btcpay-server-1-10-0/ [miningpool observer]: https://miningpool.observer/template-and-block [mempool space]: https://mempool.space/graphs/mining/block-health -[waiting for confirmation 1]: /en/blog/waiting-for-confirmation/#why-do-we-have-a-mempool +[waiting for confirmation 1]: /fr/newsletters/2023/05/17/#en-attente-de-confirmation-1--pourquoi-avons-nous-un-mempool- [reference getblocktemplate]: https://developer.bitcoin.org/reference/rpc/getblocktemplate.html -[waiting for confirmation 2]: /en/blog/waiting-for-confirmation/#incentives +[waiting for confirmation 2]: /fr/newsletters/2023/05/24/#en-attente-de-confirmation-2--mesures-dincitation [ElligatorSwift paper]: https://eprint.iacr.org/2022/759 From dac448090a555b1afc325283dc0ed2368617330c Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Tue, 1 Aug 2023 08:45:38 +0200 Subject: [PATCH 05/15] Create 07-resources-du-reseau.md --- .../policy/fr/07-resources-du-reseau.md | 92 +++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 _includes/specials/policy/fr/07-resources-du-reseau.md diff --git a/_includes/specials/policy/fr/07-resources-du-reseau.md b/_includes/specials/policy/fr/07-resources-du-reseau.md new file mode 100644 index 000000000..e36e66dc9 --- /dev/null +++ b/_includes/specials/policy/fr/07-resources-du-reseau.md @@ -0,0 +1,92 @@ +A previous post discussed protecting node resources, which may be unique to +each node and thus sometimes configurable. We also made our case for why it is best +to converge on one policy, but what should be part of that policy? This post +will discuss the concept of network-wide resources, critical to things like +scalability, upgradeability and accessibility of bootstrapping and maintaining +a full node. + +As discussed in [previous posts][policy01], many of the Bitcoin network’s +ideological goals are embodied in its distributed structure. Bitcoin's peer-to-peer +nature allows the rules of the network to emerge from rough +consensus of the individual node operators’ choices and curbs attempts to +acquire undue influence in the network. Those rules are then enforced by each +node individually validating every transaction. A diverse and healthy node +population requires that the cost of operating a node is kept low. It is hard +to scale any project with a global audience, but doing so without sacrificing +decentralization is akin to fighting with one hand tied to your back. The +Bitcoin project attempts this balancing act by being fiercely protective of its +shared network resources: the UTXO set, the data footprint of the blockchain +and the computational effort required to process it, and upgrade hooks to +evolve the Bitcoin protocol. + +There is no need to reiterate the entire blocksize war to realize that a limit +on blockchain growth is necessary to keep it affordable to run your own node. +However, blockchain growth is also dissuaded at the policy level by the +`minRelayTxFee` of 1 sat/vbyte, ensuring a minimum cost to express some of the +“[unbounded demand for highly-replicated perpetual storage][unbounded]”. + +Originally, the network state was tracked by keeping all transactions that +still had unspent outputs. This much bigger portion of the blockchain got +reduced significantly with the [introduction of the UTXO set][ultraprune] as +the means of keeping track of funds. Since then, the UTXO set has been a +central data structure. Especially during IBD, but also generally, UTXO lookups +represent a major portion of all memory accesses of a node. Bitcoin Core +already uses a [manually optimized data structure for the UTXO cache][pooled +resource], but the size of the UTXO set determines how much of it cannot fit in +a node’s cache. A larger UTXO set means more cache misses which slows down +block validation, IBD, and transaction validation speed. The dust limit is an +example of a policy that restricts the creation of UTXOs, specifically curbing +UTXOs that might never get spent because their amount [falls short][topic uneconomical outputs] of the cost +for spending them. Even so, [“dust storms” with thousands of transactions +occurred as recently as 2020][lopp storms]. + +When it became popular to use bare multisig outputs to publish data onto the +blockchain, the definition of standard transactions was amended to permit a +single OP_RETURN output as an alternative. People realized that it would be +impossible to prevent users from publishing data on the blockchain, but at +least such data would not need to live in the UTXO set forever when published +in outputs that could never be spent. Bitcoin Core 0.13.0 introduced a start-up +option `-permitbaremultisig` that users may toggle to reject unconfirmed +transactions with bare multisig outputs. + +While the consensus rules allow output scripts to be freeform, only a few +well-understood patterns are relayed by Bitcoin Core nodes. This makes it +easier to reason about many concerns in the network, including validation costs +and protocol upgrade mechanisms. For example, an input script that contains +op-codes, a P2SH input with more than 15 signatures, or a P2WSH input whose +witness stack has more than 100 items each would make a transaction +non-standard. (Check out this [policy overview][instagibbs policy zoo] for more +examples of policies and their motivations.) + +Finally, the Bitcoin protocol is a living software project that will need to +keep evolving to address future challenges and user needs. To that end, there +are a number of upgrade hooks deliberately left consensus valid but unused, +such as the annex, taproot leaf versions, witness versions, OP_SUCCESS, and a +number of no-op opcodes. However, just like attacks are hindered by the lack of +central points of failure, network-wide software upgrades involve a coordinated +effort between tens of thousands of independent node operators. Nodes will not +relay transactions that make use of any reserved upgrade hooks until their +meaning has been defined. This discouragement is meant to dissuade applications +from independently creating conflicting standards, which would make it +impossible to adopt one application’s standard into consensus without +invalidating another’s. Also, when a consensus change does happen, nodes that +do not upgrade immediately—and thus do not know the new consensus rules—cannot +be “tricked” into accepting a now-invalid transaction into their mempools. The +proactive discouragement helps nodes be forward-compatible and enables the +network to safely upgrade consensus rules without requiring a completely +synchronized software update. + +We can see that using policy to protect shared network resources aids in +protecting the network’s characteristics, and keeps paths for future protocol +development open. Meanwhile, we are seeing how the friction of growing the +network against a strictly limited blockweight has been driving adoption of +best practices, good technical design, and innovation: next week’s post +will explore mempool policy as an interface for second-layer protocols and +smart contract systems. + +[policy01]: /en/newsletters/2023/05/17/#waiting-for-confirmation-1-why-do-we-have-a-mempool +[unbounded]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html +[lopp storms]: https://blog.lopp.net/history-bitcoin-transaction-dust-spam-storms/ +[ultraprune]: https://github.com/bitcoin/bitcoin/pull/1677 +[pooled resource]: /en/newsletters/2023/05/03/#bitcoin-core-25325 +[instagibbs policy zoo]: https://gist.github.com/instagibbs/ee32be0126ec132213205b25b80fb3e8 From d6670f18e2bd71f2f9e57fe3b19ea69cc273ab47 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Tue, 1 Aug 2023 08:45:44 +0200 Subject: [PATCH 06/15] Update 2023-06-28-newsletter.md --- _posts/fr/newsletters/2023-06-28-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/fr/newsletters/2023-06-28-newsletter.md b/_posts/fr/newsletters/2023-06-28-newsletter.md index 49bfae31c..100ead371 100644 --- a/_posts/fr/newsletters/2023-06-28-newsletter.md +++ b/_posts/fr/newsletters/2023-06-28-newsletter.md @@ -80,7 +80,7 @@ pourquoi Bitcoin Core a une politique plus restrictive que celle permise par le consensus et comment les portefeuilles peuvent utiliser cette politique de la manière la plus efficace._ -{% include specials/policy/en/07-network-resources.md %} {% assign timestamp="24:46" %} +{% include specials/policy/fr/07-resources-du-reseau.md %} {% assign timestamp="24:46" %} ## Sélection de Q&R du Bitcoin Stack Exchange From 4c364497364e9e1a1388286098d078af86bc667a Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Tue, 1 Aug 2023 10:57:57 +0200 Subject: [PATCH 07/15] Update 2023-06-28-newsletter.md --- _posts/fr/newsletters/2023-06-28-newsletter.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/_posts/fr/newsletters/2023-06-28-newsletter.md b/_posts/fr/newsletters/2023-06-28-newsletter.md index 100ead371..28c86b7ee 100644 --- a/_posts/fr/newsletters/2023-06-28-newsletter.md +++ b/_posts/fr/newsletters/2023-06-28-newsletter.md @@ -1,5 +1,5 @@ --- -title: 'Bulletin hebdomadaire Bitcoin Optech #257' +title: 'Bulletin Hebdomadaire Bitcoin Optech #257' permalink: /fr/newsletters/2023/06/28/ name: 2023-06-28-newsletter-fr slug: 2023-06-28-newsletter-fr @@ -18,9 +18,9 @@ de l'infrastructure Bitcoin. ## Nouvelles -- **Prévenir l'épinglage des coinjoin avec le relais de transaction v3 :** Greg +- **Prévenir l'épinglage des coinjoin avec le relai de transaction v3 :** Greg Sanders a [posté][sanders v3cj] sur la liste de diffusion Bitcoin-Dev une - description de la manière dont les [règles de relais de transaction v3][topic v3 transaction relay] + description de la manière dont les [règles de relai de transaction v3][topic v3 transaction relay] proposées pourraient permettre de créer une transaction multipartite de type [coinjoin][topic coinjoin] qui ne serait pas vulnérable à l'[épinglage de transaction][topic transaction pinning]. Le problème spécifique de l'épinglage est que l'un des participants à une coinjoin @@ -213,7 +213,7 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], et {% include references.md %} {% include linkers/issues.md v=2 issues="6303,2701,2696,7710,2368,2367,2319,2120,2089,2077,1129" %} -[policy series]: /en/blog/waiting-for-confirmation/ +[policy series]: /fr/blog/waiting-for-confirmation/ [sanders v3cj]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021780.html [linus spec]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021781.html [BTCPay Server 1.10.3]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.10.3 From 0bd661404755c3a1ae7722058dabaf9514046781 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Tue, 1 Aug 2023 11:01:00 +0200 Subject: [PATCH 08/15] Update 2023-05-17-policy.md --- _posts/fr/2023-05-17-policy.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/_posts/fr/2023-05-17-policy.md b/_posts/fr/2023-05-17-policy.md index b9c8dd5cb..d22744594 100644 --- a/_posts/fr/2023-05-17-policy.md +++ b/_posts/fr/2023-05-17-policy.md @@ -63,6 +63,12 @@ h2:not(:first-of-type) { margin-top: 3em; } {% include specials/policy/fr/06-consistence.md %} +## Ressources du réseau + +*Originally published in [Newsletter #257](/fr/newsletters/2023/06/28/#en-attente-de-confirmation-7--ressources-du-reseau)* + +{% include specials/policy/fr/07-ressources-du-reseau.md %} + {% comment %}