From 229d0a37935278419776c010351b4a9dde58d353 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 13 Apr 2026 18:10:49 +0200 Subject: [PATCH 01/12] Create 2018-10-09-newsletter.md --- .../fr/newsletters/2018-10-09-newsletter.md | 216 ++++++++++++++++++ 1 file changed, 216 insertions(+) create mode 100644 _posts/fr/newsletters/2018-10-09-newsletter.md diff --git a/_posts/fr/newsletters/2018-10-09-newsletter.md b/_posts/fr/newsletters/2018-10-09-newsletter.md new file mode 100644 index 000000000..80a88681b --- /dev/null +++ b/_posts/fr/newsletters/2018-10-09-newsletter.md @@ -0,0 +1,216 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #16' +permalink: /fr/newsletters/2018/10/09/ +name: 2018-10-09-newsletter-fr +slug: 2018-10-09-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine consiste entièrement en résumés de plusieurs présentations notables données lors de l'atelier Scaling Bitcoin +le week-end dernier, car il y avait très peu à signaler dans nos sections habituelles Action Items, Nouvelles, et Changements notables dans +le code. Nous espérons revenir à notre format habituel la semaine prochaine. + +## Résumé de l'atelier : Scaling Bitcoin V (Tokyo 2018) + +La cinquième conférence Scaling Bitcoin s'est tenue samedi et dimanche à Tokyo, au Japon. Dans les sections ci-dessous, nous fournissons de +brefs aperçus de certaines des présentations qui, selon nous, pourraient être les plus intéressantes pour les lecteurs de ce bulletin, mais +nous recommandons également de regarder l'ensemble complet des [vidéos][] fournies par les organisateurs de l'atelier ou de lire les +[transcriptions][] fournies par Bryan Bishop. + +Pour plus de commodité, à la fin de chaque résumé nous ajoutons un lien direct vers sa vidéo et sa transcription (et son article, si +disponible). Les présentations sont listées ci-dessous dans l'ordre où elles apparaissaient dans le programme de l'atelier. + +**Avertissement :** les résumés qui suivent peuvent contenir des erreurs en raison du fait que nombre de présentations décrivaient des +sujets allant bien au-delà de l'expertise de l'auteur des résumés. + +### Ajuster la subvention de bloc de Bitcoin + +*Recherche par Anthony (AJ) Towns* + +Cette présentation mène une réflexion intellectuelle sur la question de savoir si Bitcoin paie plus pour sa sécurité qu'il n'en a +besoin---et sur ce que nous pourrions faire si nous décidions qu'il paie effectivement trop. L'orateur précise clairement qu'il s'intéresse +à l'examen des questions et à la fourniture de réponses possibles, mais qu'il ne suggère ni qu'il y ait un problème ni ne plaide pour une +quelconque solution. + +Si la base d'utilisateurs de Bitcoin pensait qu'elle surpaie la sécurité, la présentation suggère des options pour réduire le montant de +subvention versé à court terme à mesure que le niveau de sécurité augmente---tout en garantissant que pas plus de 21 millions de bitcoins ne +soient versés au total en subvention---permettant potentiellement à la subvention de durer bien plus longtemps que prévu actuellement. + +Bien que la présentation ne portât pas sur une proposition spécifique, un exemple de proposition qu'elle a évaluée consistait à réduire la +subvention de 20 % chaque fois que la sécurité de preuve de travail du réseau double (mesurée par la difficulté de création des blocs). + +*[vidéo][vid subsidy], [transcription][tx subsidy]* + +### Forward blocks : augmentations de capacité on-chain sans hard fork + +*Recherche par Mark Friedenbach* + +Une méthode bien connue pour augmenter par soft fork la taille des blocs Bitcoin est celle des extension blocks---une structure de données +qui est invisible aux nœuds qui n'ont pas été mis à niveau vers le soft fork et qui n'est donc pas soumise à leurs limites historiques sur +la taille des blocs. En soi, il s'agit d'une méthode indésirable pour augmenter la taille des blocs, car empêcher les anciens nœuds de voir +les transactions dans l'extension block les empêche également de pouvoir appliquer toute autre règle de consensus à ces transactions---comme +les règles qui empêchent un utilisateur malveillant de dépenser les bitcoins d'autres utilisateurs ou d'en créer davantage que ce qui est +autorisé par le calendrier de subvention de 21 millions de bitcoins. + +Cependant, il n'est pas nécessaire d'augmenter la taille des blocs pour accroître la quantité de données pouvant être ajoutée à la chaîne de +blocs par minute---il est aussi possible d'augmenter la capacité en augmentant la fréquence des blocs (en réduisant le temps moyen entre les +blocs). Une méthode pour détourner l'algorithme d'ajustement de difficulté de Bitcoin---appelée une attaque par déformation temporelle +(*time-warp attack*)---est bien connue parmi les experts et a été utilisée avec succès dans des attaques de démonstration contre le testnet +de Bitcoin et dans de véritables attaques contre des altcoins. (Note : bien que Bitcoin soit techniquement vulnérable à cette attaque, ce +serait une attaque lente qui donnerait à la base d'utilisateurs un temps important pour réagir.) En soi, augmenter la fréquence des blocs +est également une méthode indésirable pour accroître la capacité, car des intervalles de blocs plus courts augmentent l'efficacité des +mineurs disposant de grandes quantités de hachage et sont donc susceptibles d'accroître la centralisation du minage.[^freq-pow-waste] + +Contredisant peut-être le dicton selon lequel « deux torts ne font pas un droit », cette présentation décrit une nouvelle façon de combiner +les extension blocks et l'attaque par déformation temporelle afin de permettre aux nœuds mis à niveau comme aux anciens nœuds de bénéficier +de la même augmentation de capacité et de voir toutes les mêmes transactions pour leur validation, tout en réduisant simultanément +légèrement le risque de centralisation du minage. Les nœuds mis à niveau valideraient un ou plusieurs extension blocks (appelés « forward +blocks ») qui fournissent de l'espace de bloc supplémentaire avec un intervalle moyen de 15 minutes réduisant la centralisation, mais les +nœuds mis à niveau restreindraient également les horodatages dans les blocs hérités afin d'assurer une attaque par déformation temporelle +permanente (mais limitée) augmentant la fréquence des blocs hérités suffisamment pour leur permettre d'inclure les mêmes transactions qui +apparaissaient auparavant dans les forward blocks. + +*[vidéo][vid forward blocks], [transcription][tx forward blocks], [article][paper forward blocks]* + +### Signatures multiples compactes pour des blockchains plus petites + +*Recherche par Dan Boneh, Manu Drijvers, et Gregory Neven* + +Cette présentation décrit une alternative au schéma de signature Schnorr décrit dans le [document MuSig][] qui utilise la [cryptographie +basée sur les appariements][], spécifiquement une adaptation du [schéma de signature Boneh--Lynn--Shacham (BLS)][bls sigs]. Bien que les +schémas basés sur les appariements exigent une hypothèse de sécurité fondamentale supplémentaire au-delà de celles faites à la fois par le +schéma ECDSA actuel de Bitcoin et par le schéma Schnorr proposé, les auteurs présentent des éléments montrant que leur schéma produirait des +signatures généralement plus petites, permettrait une agrégation de signatures non interactive, et rendrait possible de prouver quels +membres de l'ensemble des signataires ont effectivement travaillé ensemble pour créer une signature à seuil (c.-à-d. k-sur-m signataires, +par ex. multisig 2-sur-3). + +*[vidéo][vid bls msig], [transcription][tx bls msig], [article (pre-print)][paper bls msig]* + +### Accumulateurs : un remplacement évolutif prêt à l'emploi pour les arbres de merkle + +*Recherche par Benedikt Bünz, Benjamin Fisch, et Dan Boneh* + +Dans Bitcoin et d'autres cryptomonnaies, les engagements évolutifs envers des ensembles d'informations---comme les transactions ou les +UTXO---sont normalement réalisés à l'aide d'arbres de merkle qui permettent de prouver qu'un élément est membre de l'ensemble en générant +une preuve dont la taille et le coût de validation sont approximativement de *log2(n)* pour un ensemble de *n* éléments. + +Cette présentation décrit une méthode alternative basée sur des accumulateurs RSA qui offre des avantages potentiels : la taille d'une +preuve est constante quel que soit le nombre d'éléments membres de l'ensemble, et l'ajout ou la suppression d'éléments d'un accumulateur +peut être efficacement regroupé (par ex. une mise à jour par bloc). + +*[vidéo][vid accumulators], [transcription][tx accumulators]* + +### ECDSA multipartite pour des canaux de paiement Lightning Network sans script + +*Recherche par Conner Fromknecht* + +Les canaux de paiement routables tels que ceux utilisés par le Lightning Network utilisent actuellement plusieurs opcodes du langage Script +qui sont appliqués par les règles de consensus de Bitcoin. Des travaux antérieurs sur les [scripts sans script][scriptless scripts +transcript] par Andrew Poelstra ont [suggéré][ln scriptless scripts] que certains ou la totalité des opcodes actuellement utilisés +pourraient être remplacés par des clés publiques Schnorr et des signatures qui seraient créées en privé (offchain) entre les participants +du canal de paiement. Les règles de consensus exigeraient toujours qu'une transaction de dépense ait une signature valide faisant référence +à une clé publique connue, mais aucune des autres informations liées à la sécurité n'apparaîtrait onchain, réduisant la consommation de +données et les frais, améliorant la confidentialité et la fongibilité, et améliorant potentiellement la sécurité. + +Bitcoin ne prend actuellement pas en charge les signatures Schnorr et aucune conception complète pour cela n'a été proposée (bien qu'une +telle proposition puisse ne pas être bien loin), donc cette présentation décrit des résultats de preuve de concept issus d'une +implémentation partielle de scripts sans script pour canaux de paiement qui est compatible avec les clés et signatures ECDSA actuelles de +Bitcoin. Des économies impressionnantes sont obtenues sur la taille des scripts et des données witness---des économies qui augmentent le +nombre de canaux pouvant être ouverts ou fermés dans un bloc et qui réduisent le montant des frais de transaction payés par les utilisateurs +de canaux de paiement Lightning Network. + +*[vidéo][vid scriptless ecdsa], [transcription][tx scriptless ecdsa]* + +## Discussion : l'évolution du script bitcoin + +Un groupe de discussion de deux heures centré sur ce sujet a mentionné une grande variété de modifications proposées au langage Script de +Bitcoin---bien trop nombreuses pour être mentionnées ici, même sous forme de résumé. Cependant, quelques modifications ont été mentionnées +comme théoriquement réalisables en 2019 si la communauté est prête à les adopter : + +- **Schéma de signature Schnorr :** une fonctionnalité optionnelle fournissant des signatures plus petites dans tous les cas, une validation + plus rapide, des données de clé publique et de signature beaucoup plus petites pour les multisigs coopératifs, et une compatibilité plus + aisée avec les scripts sans script. Voir la [proposition de BIP][schnorr pre-bip] de Pieter Wuille. + +- **SIGHASH_NOINPUT_UNSAFE :** la capacité de créer des dépenses sans référencer explicitement quelle sortie vous souhaitez dépenser. Permet + de créer des canaux de paiement plus efficaces en utilisant le [protocole Eltoo][] qui permet aussi facilement à chaque canal de prendre + en charge jusqu'à 150 participants. Voir [BIP118][]. + +- **OP_CHECKSIGFROMSTACK :** rend possible la création de covenants qui restreignent les sorties vers lesquelles une pièce particulière peut + être dépensée. Par exemple, vous pourriez imposer un délai obligatoire d'une semaine sur les dépenses provenant de votre portefeuille à + froid. Pendant ce délai, vous ne pourriez dépenser les pièces qu'en les renvoyant dans votre portefeuille à froid. Mais si vous attendiez + l'expiration du délai, vous pourriez dépenser les pièces vers n'importe quelle adresse arbitraire. Cela signifie que si quelqu'un volait + une copie de la clé privée de votre portefeuille à froid, vous pourriez utiliser ce mécanisme pour l'empêcher de dépenser vos bitcoins en + les renvoyant dans votre portefeuille à froid pendant la période de délai. (Il a été noté que certains développeurs s'opposent à + l'activation de la forme la plus simple de cet opcode pour des raisons de fongibilité, bien que des approches alternatives puissent être + davantage acceptables.) + +- **Correction du bug de déformation temporelle :** un ensemble de mineurs contrôlant la majorité du taux de hachage peut actuellement + manipuler l'algorithme d'ajustement de difficulté de Bitcoin pour leur permettre de créer de façon constante plus d'un bloc toutes les dix + minutes, même sans augmenter le taux de hachage global. Il existe au moins une proposition simple pour réduire la quantité de manipulation + possible sans casser les logiciels plus anciens ni le matériel de minage. Voir le récent [fil de discussion par e-mail][bitcoin-dev + timewarp] sur la liste de diffusion Bitcoin-Dev. + +- **Frais explicites :** actuellement les frais dans Bitcoin sont implicites via la différence entre la valeur des entrées agrégées et celle + des sorties agrégées. Cependant, la transaction pourrait alternativement s'engager explicitement sur les frais et permettre que l'une des + sorties soit fixée à la différence entre la valeur des entrées agrégées et les frais explicites plus toutes les autres sorties. Cela + pourrait être utile pour récompenser les watchtowers du Lightning Network qui envoient des transactions de remédiation de violation pour + le compte d'utilisateurs hors ligne, ou cela pourrait être utile pour l'augmentation des frais de transactions de groupe. + +Cependant, un membre du groupe de discussion a suggéré que « les seules personnes à l'aise avec les soft forks sont peu susceptibles de +proposer un soft fork et de produire un logiciel qui serait adopté. Les gens vont combattre tout ce qui ajoute quoi que ce soit, surtout +compte tenu du récent [CVE][CVE-2018-17144]. Les gens vont être, pendant les 6 prochains mois, significativement plus conservateurs. Il +faudra encore 6 mois avant que les gens n'envisagent même cela. Je ne pense pas que nous allons obtenir de nouveaux soft forks dans l'année +qui vient. » + +*(pas de vidéo), [transcription][tx script]* + +## Remerciements particuliers + +Nous remercions Andrew Poelstra, Anthony Towns, Bryan Bishop, et Pieter Wuille pour avoir fourni des suggestions ou répondu à des questions +liées au contenu de ce bulletin. Toute erreur restante est entièrement de la faute de l'auteur du bulletin. + +## Notes de bas de page + +[^freq-pow-waste]: Lorsqu'un mineur crée un nouveau bloc à la pointe de la chaîne, il peut commencer à travailler immédiatement sur le bloc +suivant---mais tous les autres mineurs travaillent encore sur un ancien bloc jusqu'à ce qu'ils reçoivent le nouveau bloc, ce qui signifie +que leur preuve de travail pendant cette brève période est gaspillée (elle n'augmente ni la sécurité du réseau ni ne fournit aux mineurs une +compensation financière). Les mineurs disposant de plus de taux de hachage produisent davantage de blocs en moyenne, ils obtiennent donc +cette avance plus souvent et une plus petite partie de leur preuve de travail est gaspillée. + + Pour deux mineurs parfaitement équitables séparés par la moitié du globe, le délai réseau pratique minimal entre eux est d'environ 0,2 + seconde, ce qui signifie qu'un petit mineur éloigné de la plupart des autres mineurs n'est probablement productif que pendant 599,8 + secondes sur la moyenne de 600,0 secondes (dix minutes) entre les blocs. Une perte d'efficacité de 0,2/600,0 (0,03 %) est probablement + acceptable, mais si la fréquence des blocs était augmentée, la perte d'efficacité augmenterait également : à un bloc par minute, la + perte d'efficacité serait de 0,33 % ; à un bloc toutes les six secondes, de 3,33 %. + + Le petit mineur pourrait augmenter son efficacité en se rapprochant des autres mineurs ou même éliminer complètement la perte + d'efficacité en fusionnant avec eux, mais c'est cette centralisation du minage qu'il est essentiel d'éviter dans Bitcoin si nous voulons + empêcher les mineurs de pouvoir censurer facilement quelles transactions sont incluses dans les blocs. + +{% include references.md %} + +[videos]: https://tokyo2018.scalingbitcoin.org/#remote-participation +[transcriptions]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/ +[vid subsidy]: https://youtu.be/y8hJ0VTPE34?t=39 +[tx subsidy]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/playing-with-fire-adjusting-bitcoin-block-subsidy/ +[vid forward blocks]: https://youtu.be/y8hJ0VTPE34?t=3744 +[tx forward blocks]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/forward-blocks/ +[paper forward blocks]: http://freico.in/forward-blocks-scalingbitcoin-paper.pdf +[vid bls msig]: https://youtu.be/IMzLa9B1_3E?t=29 +[tx bls msig]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/compact-multi-signatures-for-smaller-blockchains/ +[paper bls msig]: https://eprint.iacr.org/2018/483.pdf +[vid accumulators]: https://youtu.be/IMzLa9B1_3E?t=3522 +[tx accumulators]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/accumulators/ +[vid scriptless ecdsa]: https://youtu.be/3mJURLD2XS8?t=3624 +[tx scriptless ecdsa]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/scriptless-ecdsa/ +[tx script]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/bitcoin-script/ +[document musig]: https://eprint.iacr.org/2018/068 +[schnorr pre-bip]: https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki +[cryptographie basée sur les appariements]: https://en.wikipedia.org/wiki/Pairing-based_cryptography +[bls sigs]: https://en.wikipedia.org/wiki/Boneh%E2%80%93Lynn%E2%80%93Shacham +[scriptless scripts transcript]: https://scalingbitcoin.org/transcript/stanford2017/using-the-chain-for-what-chains-are-good-for +[protocole Eltoo]: https://blockstream.com/2018/04/30/eltoo-next-lightning.html +[bitcoin-dev timewarp]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016316.html +[ln scriptless scripts]: https://lists.launchpad.net/mimblewimble/msg00086.html +[cve-2018-17144]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17144 From 7826d9251319e6a09bd745b2d380507f73c43137 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 13 Apr 2026 18:10:53 +0200 Subject: [PATCH 02/12] Create 2018-10-02-newsletter.md --- .../fr/newsletters/2018-10-02-newsletter.md | 70 +++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 _posts/fr/newsletters/2018-10-02-newsletter.md diff --git a/_posts/fr/newsletters/2018-10-02-newsletter.md b/_posts/fr/newsletters/2018-10-02-newsletter.md new file mode 100644 index 000000000..4d90da4a5 --- /dev/null +++ b/_posts/fr/newsletters/2018-10-02-newsletter.md @@ -0,0 +1,70 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #15' +permalink: /fr/newsletters/2018/10/02/ +name: 2018-10-02-newsletter-fr +slug: 2018-10-02-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine comprend un avis concernant la sortie imminente de Bitcoin Core 0.17, des liens vers les versions rétroportées +de Bitcoin Core 0.15 et 0.14 pour corriger le bug d'entrées dupliquées CVE-2018-17144 pour les utilisateurs incapables d'exécuter des +versions plus récentes, une brève description d'une scission de chaîne sur testnet, et des liens vers des fusions notables dans des projets +d'infrastructure Bitcoin. + +## Action à mener + +- **Mettez à niveau vers Bitcoin Core 0.17 :** la nouvelle version a été taguée et plusieurs personnes ont commencé à reproduire des builds + du logiciel, donc les binaires et l'annonce officielle de sortie devraient vraisemblablement devenir disponibles mardi ou mercredi sur + [BitcoinCore.org][]. L'annonce inclura une copie des notes de version détaillant les principaux changements apportés au logiciel depuis la + version 0.16.0. + +## Nouvelles + +- **Bitcoin Core [0.15.2][] et [0.14.3][] publiés :** bien que le code source ait été disponible pour ces anciennes branches depuis + l'annonce publique du bug d'entrées dupliquées [CVE-2018-17144][], obtenir suffisamment de personnes pour certifier un build reproductible + a nécessité plus de temps avant que les [binaires][bcco /bin] puissent être mis à disposition. + +- **Bug d'entrées dupliquées CVE-2018-17144 exploité sur testnet :** jeudi dernier, un bloc a été créé sur testnet contenant une transaction + qui dépensait la même entrée deux fois. Comme prévu, les nœuds considérés comme vulnérables au bug ont accepté le bloc et tous les autres + nœuds l'ont rejeté, conduisant à une défaillance du consensus (scission de chaîne) où la chaîne ayant la plus grande preuve de travail + contenait les entrées dupliquées et une chaîne plus faible n'en contenait pas. + + Finalement, la chaîne sans les entrées dupliquées a accumulé davantage de preuve de travail et les nœuds vulnérables ont tenté de basculer + vers elle. Cela a amené les nœuds vulnérables à tenter de réajouter l'entrée dupliquée à la base de données UTXO deux fois, déclenchant un + assert et provoquant leur arrêt. Lors du redémarrage, les opérateurs des nœuds vulnérables ont dû déclencher manuellement une longue + procédure de réindexation pour corriger les incohérences de la base de données de leurs nœuds. (Cet effet secondaire de la récupération + après une scission de chaîne avec entrées dupliquées était déjà connu des développeurs.) + + Les nœuds mis à niveau vers Bitcoin Core 0.16.3, 0.17.0RC4, ou exécutant un autre logiciel qui n'était pas vulnérable n'ont signalé aucun + problème. Cependant, de nombreux explorateurs de blocs avec un mode testnet ont bien accepté le bloc vulnérable, rappelant aux + utilisateurs qu'ils doivent être prudents lorsqu'ils utilisent des tiers pour déterminer si des transactions sont valides ou non. + +## Changements notables dans le code + +*Changements notables dans le code cette semaine dans [Bitcoin Core][bitcoin core repo], [LND][lnd repo], et [C-lightning][core lightning +repo].* + +- [Bitcoin Core #14305][] : après la découverte de quelques cas où des tests basés sur Python réussissaient incorrectement en raison de + l'utilisation de variables mal nommées, une liste blanche de noms de variables a été implémentée en utilisant la fonctionnalité + `__slots__` de Python 3 pour les classes. + +- [LND #1987][] : la RPC `NewWitnessAddress` a été supprimée et la RPC `NewAddress` ne prend désormais en charge que la génération + d'adresses pour P2SH-encapsulé P2WKH et P2WPKH natif. + +- [C-Lightning #1982][] : la RPC `invoice` implémente désormais [RouteBoost][] en incluant un paramètre `r` [BOLT11][] dans la facture qui + fournit des informations de routage au payeur pour un canal déjà ouvert ayant la capacité de prendre en charge le paiement de la facture. + Ce paramètre était à l'origine destiné à aider à la prise en charge des routes privées, mais il peut aussi être utilisé de cette manière + pour prendre en charge des nœuds qui ne souhaitent plus accepter de nouveaux canaux entrants. Alternativement, si aucun canal disponible + ne peut prendre en charge le paiement de la facture, C-Lightning émettra un avertissement. + +{% include references.md %} +{% include linkers/issues.md issues="14305,1987,1982" %} + +[0.16.3]: https://bitcoincore.org/en/2018/09/18/release-0.16.3/ +[0.15.2]: https://github.com/bitcoin/bitcoin/releases/tag/v0.15.2 +[0.14.3]: https://github.com/bitcoin/bitcoin/releases/tag/v0.14.3 +[cve-2018-17144]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17144 +[bcc 0.17]: https://bitcoincore.org/bin/bitcoin-core-0.17.0/ +[bcco /bin]: https://bitcoincore.org/bin/ +[routeboost]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-September/001417.html From 8b83166d042e6d4c8d112750e7652305b63b27fa Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 13 Apr 2026 18:17:32 +0200 Subject: [PATCH 03/12] Create 2018-10-16-newsletter.md --- .../fr/newsletters/2018-10-16-newsletter.md | 106 ++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 _posts/fr/newsletters/2018-10-16-newsletter.md diff --git a/_posts/fr/newsletters/2018-10-16-newsletter.md b/_posts/fr/newsletters/2018-10-16-newsletter.md new file mode 100644 index 000000000..0eeaa2a68 --- /dev/null +++ b/_posts/fr/newsletters/2018-10-16-newsletter.md @@ -0,0 +1,106 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #17' +permalink: /fr/newsletters/2018/10/16/ +name: 2018-10-16-newsletter-fr +slug: 2018-10-16-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine décrit brièvement une proposition de splice pour les canaux de paiement du Lightning Network, fournit des liens +vers les vidéos et transcriptions des présentations des sessions de formation Edge Dev++, et résume certaines transcriptions réalisées lors +de l'événement CoreDev.tech de la semaine dernière. + +## Éléments d'action + +Aucun cette semaine. + +## Nouvelles + +- **Proposition de splice pour les canaux de paiement du Lightning Network :** le splice est une idée permettant aux utilisateurs soit + d'ajouter soit de retirer des fonds d'un canal de paiement existant sans le délai nécessaire pour fermer et rouvrir un canal entièrement + nouveau. Rusty Russell a publié une [proposition technique][complex splice] permettant un seul splice à la fois, bien qu'il note que la + proposition est complexe. René Pickhardt a décrit une [alternative][simpler splice] qui serait probablement plus facile à implémenter et à + analyser, mais qui pourrait nécessiter davantage de transactions onchain. Il a été suggéré que la solution plus simple mais plus coûteuse + pourrait être la version 1, et la solution plus complexe mais moins coûteuse pourrait être la version 2. + +- **Publications des présentations d'Edge Dev++ :** une série de présentations de deux jours par des contributeurs Bitcoin de premier plan + destinée aux développeurs a été publiée sous forme de [vidéos][dev vids] et de [transcriptions][dev transcripts]. Les présentations + couvrent toute la gamme des sujets, de l'introduction à l'avancé. Trois présentations pourraient être particulièrement intéressantes pour + les membres d'Optech : + + 1. *Sécurité des plateformes d'échange* par Warren Togami. Décrit les causes de plusieurs vols majeurs notables sur des plateformes + d'échange Bitcoin et altcoin et énumère un certain nombre de techniques que les entreprises peuvent utiliser pour réduire leur risque + de perte. ([Vidéo][warren vid], [transcription][warren transcript]) + + 2. *Sécurité des portefeuilles, gestion des clés et modules matériels de sécurité (HSM)]* par Bryan Bishop. Suggère des méthodes pour + diminuer le risque que des clés privées soient volées ou utilisées à mauvais escient. ([Vidéo][kanzure wallet vid], + [transcription][kanzure wallet transcript]) + + 3. *Gestion des réorganisations et des forks* par Bryan Bishop. Décrit comment sécuriser vos transactions contre des changements dans la + chaîne de blocs Bitcoin ou dans les règles de consensus, y compris des suggestions sur la manière de tester vos systèmes. + ([Vidéo][kanzure reorg vid], [transcription][kanzure reorg transcript]) + +## CoreDev.tech + +CoreDev.tech est un événement sur invitation uniquement pour des contributeurs bien connus de projets d'infrastructure Bitcoin tels que +Bitcoin Core et Lightning Network. Les discussions ne sont pas enregistrées, mais Bryan Bishop rédige utilement des transcriptions +approximatives et non officielles de certaines des discussions pendant les événements. Les courts résumés suivants sont basés sur certaines +des transcriptions de l'événement de la semaine dernière à Tokyo : + +- **[Bitcoin Optech][optech transcript] :** Bitcoin Optech est présenté et brièvement discuté, suivi d'une discussion sur les problèmes + courants que rencontrent les entreprises utilisant Bitcoin lorsqu'elles utilisent Bitcoin Core et d'autres projets d'infrastructure open + source. + +- **[Utilisation d'accumulateurs UTXO pour réduire les besoins de stockage de données][utreexo] :** Tadge Dryja décrit le travail qu'il a + effectué sur des accumulateurs UTXO qui sont similaires dans leur fonction à ceux décrits dans le bulletin de la semaine dernière mais qui + ont une construction différente basée sur des hachages. Il décrit en outre comment ils pourraient être combinés avec quelque chose comme + l'idée [UTXO Hash Set (UHO)][UHO] de Cory Fields afin que les nœuds complets stockent des hachages d'UTXO au lieu d'UTXO complets pour + réduire significativement la quantité de stockage utilisée par les nœuds complets élagués sans nécessairement exiger de modifications des + règles de consensus. + +- **[Descripteurs de script et DESCRIPT][script descriptors and descript] :** la manière rétrocompatible par défaut dont les portefeuilles + tels que Bitcoin Core surveillent les sorties de transaction qui leur paient "est ambiguë, inflexible et passe mal à l'échelle". Les + [descripteurs de script de sortie][output script descriptors] sont un langage simple pour décrire des scripts au portefeuille, ce qui + permet au portefeuille de gérer plus facilement de nombreux cas normaux (y compris les importations de clés privées et publiques étendues + HD). + + Dans un registre quelque peu lié, DESCRIPT est un langage qui utilise un sous-ensemble du langage complet Bitcoin Script pour faciliter la + construction de certaines politiques simples. "Nous avons un compilateur DESCRIPT qui prend quelque chose que nous appelons un langage de + politique (AND, OR, seuil, clé publique, hashlock, timelock) ainsi que des probabilités pour chaque OR afin d'indiquer si c'est 50/50 ou + si un côté du OR est plus probable que le côté droit, et il trouvera [...] le script optimal dans ce sous-ensemble de script que nous + avons défini." Par exemple, cela pourrait vous permettre "de faire quelque chose comme un multisig qui après un certain temps se dégrade + en un multisig plus faible --- comme un 2-sur-3 mais après un an je peux le dépenser avec seulement une de ces clés." + +## Changements notables dans le code + +*Changements notables dans le code cette semaine dans [Bitcoin Core][bitcoin core repo], [LND][lnd repo] et [C-lightning][core lightning +repo].* + +- [LND #1970][] : la méthode RPC AbandonChannel (disponible uniquement dans le mode de débogage développeur) fournit désormais des + informations supplémentaires lorsque les utilisateurs demandent à leur nœud d'abandonner un canal de paiement (une méthode pouvant + provoquer une perte monétaire si elle est utilisée sans précaution). Les informations supplémentaires sont suffisantes pour permettre soit + de redémarrer ultérieurement un canal de paiement ouvert soit de prouver que le programme disposait de suffisamment d'informations pour + prendre des engagements supplémentaires sur un canal de paiement maintenant fermé. + +- [C-Lightning #2000][] : cela fournit un grand nombre de correctifs et d'améliorations liées à la sécurité concernant la manière dont les + contrats à verrouillage par hachage et délai (HTLC) sont stockés dans la base de données. + +{% include references.md %} +{% include linkers/issues.md issues="1970,2000" %} + +[complex splice]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001434.html +[simpler splice]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-October/001437.html +[script descriptors and descript]: https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2018-10-08-script-descriptors/ +[utreexo]: https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2018-10-08-utxo-accumulators-and-utreexo/ +[optech transcript]: https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2018-10-09-bitcoin-optech/ +[dev vids]: https://www.youtube.com/channel/UCywSzGiWWcUG1gTp45YdPUQ/videos +[dev transcripts]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/edgedevplusplus/ +[warren transcript]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/edgedevplusplus/protecting-yourself-and-your-business/ +[warren vid]: https://youtu.be/iPt2ekHoEy8 +[kanzure wallet transcript]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/edgedevplusplus/wallet-security/ +[kanzure wallet vid]: https://youtu.be/WcOIXsOLJ3w?t=3552 +[kanzure reorg transcript]: http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/edgedevplusplus/reorgs/ +[kanzure reorg vid]: https://youtu.be/EUUQbveGF5E?t=4 +[UHO]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015967.html +[output script descriptors]: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md From dc4f909c89a64facc2f14b03de43373593f8fba7 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 13 Apr 2026 18:28:25 +0200 Subject: [PATCH 04/12] Create 2018-10-23-newsletter.md --- .../fr/newsletters/2018-10-23-newsletter.md | 128 ++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 _posts/fr/newsletters/2018-10-23-newsletter.md diff --git a/_posts/fr/newsletters/2018-10-23-newsletter.md b/_posts/fr/newsletters/2018-10-23-newsletter.md new file mode 100644 index 000000000..32c2035d4 --- /dev/null +++ b/_posts/fr/newsletters/2018-10-23-newsletter.md @@ -0,0 +1,128 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #18' +permalink: /fr/newsletters/2018/10/23/ +name: 2018-10-23-newsletter-fr +slug: 2018-10-23-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine contient un avertissement concernant la communication avec des nœuds Bitcoin via RPC sur des connexions non +chiffrées, des liens vers deux nouveaux articles sur la création rapide de clés et de signatures ECDSA multipartites qui pourraient réduire +les frais de transaction pour les utilisateurs de multisig, et répertorie quelques fusions notables de projets populaires d'infrastructure +Bitcoin. + +## Actions requises + +- **Fermez les ports RPC ouverts sur les nœuds :** environ 13 % des nœuds Bitcoin semblent avoir leurs ports RPC ouverts sur des connexions + publiques non chiffrées, mettant les utilisateurs de ces nœuds en danger. Voir l’élément d’actualité complet ci-dessous pour plus de + détails sur le risque et les solutions recommandées. + +## Nouvelles + +- **Plus de 1 100 nœuds à l’écoute ont des ports RPC ouverts :** Il a été récemment mentionné dans le salon IRC #bitcoin-core-dev que de + nombreux nœuds Bitcoin sur le réseau avaient leur port RPC ouvert. Optech a [enquêté][port scan summary] et a constaté qu’environ 1 100 + des 8 400 nœuds à l’écoute avec une adresse IPv4 avaient bien le port 8332 ouvert (13,2 %). + + Cela peut indiquer que de nombreux opérateurs de nœuds ignorent que la communication RPC sur Internet est complètement non sécurisée par + défaut et expose votre nœud à de multiples attaques qui pourraient vous coûter de l’argent même si vous avez désactivé le portefeuille sur + votre nœud. La communication RPC n’est pas chiffrée, donc tout espion observant ne serait-ce qu’une seule requête vers votre serveur peut + voler vos identifiants d’authentification et les utiliser pour exécuter des commandes qui vident votre portefeuille (si vous en avez un), + tromper votre nœud pour qu’il utilise une bifurcation de la chaîne de blocs avec presque aucune sécurité de preuve de travail, écraser des + fichiers arbitraires sur votre système de fichiers, ou causer d’autres dommages. Même si vous ne vous connectez jamais à votre nœud via + Internet, avoir un port RPC ouvert comporte le risque qu’un attaquant devine vos identifiants de connexion. + + Par défaut, les nœuds n’acceptent pas les connexions RPC depuis un autre ordinateur---vous devez activer une option de configuration pour + autoriser les connexions RPC. Pour déterminer si vous avez activé cette fonctionnalité, vérifiez dans votre fichier de configuration + Bitcoin et vos paramètres de démarrage la présence du paramètre `rpcallowip`. Si cette option est présente, vous devriez la supprimer et + redémarrer votre nœud à moins d’avoir une bonne raison de croire que toutes les connexions RPC à votre nœud sont chiffrées ou sont + limitées à un réseau privé de confiance. Si vous souhaitez tester votre nœud à distance pour détecter un port RPC ouvert, vous pouvez + exécuter la commande [nmap][] suivante après avoir remplacé *ADDRESS* par l’adresse IP de votre nœud : + + ``` + nmap -Pn -p 8332 ADDRESS + ``` + + Si le résultat dans le champ *state* est « open », vous devriez suivre les instructions ci-dessus pour supprimer le paramètre + `rpcallowip`. Si le résultat est soit « closed » soit « filtered », votre nœud est sûr à moins que vous n’ayez défini un port RPC + personnalisé ou activé autrement une configuration personnalisée. + + Une [PR][Bitcoin Core #14532] a été ouverte pour Bitcoin Core afin de rendre plus difficile pour les utilisateurs de configurer leur nœud + de cette façon et d’afficher des avertissements supplémentaires lors de l’activation d’un tel comportement. + +- **Deux articles publiés sur l’ECDSA multipartite rapide :** dans l’ECDSA multipartite, deux parties ou plus peuvent créer en coopération + (mais sans confiance) une seule clé publique qui exige également que les parties coopèrent pour créer une seule signature valide pour + cette clé publique. Si les parties s’accordent avant de créer la clé publique, elles peuvent aussi rendre possible qu’un sous-ensemble + d’entre elles seulement signe, par ex. 2 sur 3 d’entre elles doivent coopérer pour signer. Cela peut être beaucoup plus efficace que le + multisig actuel de Bitcoin, qui nécessite de placer *k* signatures et *n* clés publiques dans les transactions pour une sécurité k-sur-n, + alors que l’ECDSA multipartite ne nécessiterait toujours qu’une seule signature et une seule clé publique pour n’importe quels *k* ou *n*. + Les techniques sous-jacentes à l’ECDSA multipartite peuvent également être utilisées avec des scriptless scripts comme décrit dans le + [Bulletin #16][news16 mpecdsa]. + + Mieux encore, ces avantages sont immédiatement disponibles pour quiconque les implémente, car la prise en charge actuelle de l’ECDSA par + le protocole Bitcoin signifie qu’il prend également en charge les schémas multipartites ECDSA purs. Aucun changement n’est nécessaire aux + règles de consensus, au protocole P2P, aux formats d’adresse, ni à aucune autre ressource partagée. Tout ce dont vous avez besoin, ce sont + de deux portefeuilles ou plus qui implémentent la génération de clés et la signature ECDSA multipartites. Cela peut rendre le schéma + attrayant pour les services existants qui bénéficient de la sécurité supplémentaire du multisig Bitcoin mais perdent à devoir payer des + frais de transaction supplémentaires pour les clés publiques et signatures supplémentaires. + + Il faudra probablement du temps pour que les experts examinent ces articles, évaluent leurs propriétés de sécurité et envisagent de les + implémenter---et certains experts sont déjà occupés à travailler sur l’implémentation d’une proposition de modification du consensus pour + permettre un schéma de signature Schnorr qui peut simplifier la génération de clés publiques et de signatures multipartites et aussi + fournir de multiples autres avantages. + + - [Fast Multiparty Threshold ECDSA with Fast Trustless Setup][mpecdsa goldfeder] par Rosario Gennaro et Steven Goldfeder + + - [Fast Secure Multiparty ECDSA with Practical Distributed Key Generation and Applications to Cryptocurrency Custody][mpecdsa lindell] par + Yehuda Lindell, Ariel Nof, et Samuel Ranellucci + +[mpecdsa goldfeder]: http://stevengoldfeder.com/papers/GG18.pdf +[mpecdsa lindell]: https://eprint.iacr.org/2018/987.pdf + +## Fusions notables + +*Changements de code notables cette semaine dans [Bitcoin Core][bitcoin core repo], [LND][lnd repo], [C-lightning][core lightning repo], et +[libsecp256k1][libsecp256k1 repo].* + +- [Bitcoin Core #14291][] : Pour une utilisation avec le mode multiwallet de Bitcoin Core, un nouveau RPC `listwalletdir` peut lister tous + les portefeuilles disponibles dans le répertoire des portefeuilles. + +- [Bitcoin Core #14424][] : Corrige une régression probable dans la 0.17.0 pour les portefeuilles en surveillance seule qui obligent les + utilisateurs à importer leurs clés publiques pour les scripts multisig (plutôt que simplement importer le script) afin que Bitcoin Core + tente de dépenser le script en utilisant des RPC tels que [fundrawtransaction][rpc fundrawtransaction] avec l’indicateur + `includeWatching`. Cette PR a été marquée pour rétroportage vers la 0.17.1 dès que le travail sur celle-ci commencera. Une solution de + contournement pour les utilisateurs de la 0.17.0 est décrite dans [Bitcoin Core #14415][]. + +- [LND #1978][], [#2062][LND #2062], [#2063][LND #2063] : de nouvelles fonctions pour créer des transactions de sweep ont été ajoutées, + remplaçant des fonctions de l’UTXO Nursery qui est « dédiée à l’incubation des sorties verrouillées dans le temps ». Ces nouvelles + fonctions acceptent une liste de sorties, génèrent une transaction pour elles avec des frais appropriés qui reviennent vers le même + portefeuille (pas une adresse réutilisée), et signent la transaction. Les transactions de sweep définissent nLockTime à la hauteur + actuelle de la chaîne de blocs, implémentant la même technique anti-fee sniping adoptée par d’autres portefeuilles tels que Bitcoin Core + et GreenAddress, aidant à décourager les réorganisations de chaîne et permettant aux transactions de sweep de LND de se fondre parmi les + transactions de ces autres portefeuilles. + +- [LND #2051][] : garantit qu’un attaquant qui choisit de verrouiller ses fonds pendant une très longue période (jusqu’à environ 10 000 ans) + ne peut pas amener votre nœud à verrouiller la même quantité de vos fonds pendant la même durée. Avec ce correctif, votre nœud rejettera + les requêtes d’un attaquant visant à verrouiller ses fonds et vos fonds pour une période de plus de 5 000 blocs (environ 5 semaines). + +- [C-Lightning #2033][] : fournit un nouveau RPC `listforwards` qui liste les paiements relayés (paiements effectués dans des canaux de + paiement passant par votre nœud), y compris des informations sur le montant des frais que vous avez gagnés en faisant partie du chemin de + relais. De plus, le RPC `getstats` renvoie maintenant un nouveau champ, `msatoshis_fees_collected`, contenant le montant total des frais + que vous avez gagnés. + +- [Libsecp256k1 #354][] : permet aux appelants des fonctions ECDH d’utiliser une fonction de hachage personnalisée. Le protocole de + consensus Bitcoin n’utilise pas ECDH, mais il est utilisé ailleurs avec les mêmes paramètres de courbe que Bitcoin dans des schémas + décrits dans les BIP [47][BIP47], [75][BIP75], et [151][BIP151] (ancien brouillon) ; les BOLT Lightning [4][BOLT4] et [8][BOLT8] ; et + divers autres usages comme [Bitmessage][], les sidechains [ElementsProject][] utilisant des transactions et des actifs confidentiels, et + certains smart contracts Ethereum. Certains de ces schémas ne peuvent pas utiliser la fonction de hachage par défaut utilisée par + libsecp256k1, donc cette PR fusionnée permet de passer un pointeur vers une fonction de hachage personnalisée qui sera utilisée à la place + de la valeur par défaut et qui permet de transmettre des données arbitraires à cette fonction. + +{% include references.md %} +{% include linkers/issues.md issues="14291,14424,1978,2062,2063,2051,2033,354,14415,14532" %} + +[bitmessage]: https://bitmessage.org/wiki/Encryption +[elementsproject]: https://elementsproject.org/ +[port scan summary]: https://gist.github.com/harding/bf6115a567e80ba5e737242b91c97db2 +[nmap]: https://nmap.org/download.html +[news16 mpecdsa]: /fr/newsletters/2018/10/09/#ecdsa-multipartite-pour-des-canaux-de-paiement-lightning-network-sans-script From 400d45e96728289cd227b20bed1c83f6fac4ccdd Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 13 Apr 2026 18:46:21 +0200 Subject: [PATCH 05/12] Create 2018-10-30-newsletter.md --- .../fr/newsletters/2018-10-30-newsletter.md | 172 ++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 _posts/fr/newsletters/2018-10-30-newsletter.md diff --git a/_posts/fr/newsletters/2018-10-30-newsletter.md b/_posts/fr/newsletters/2018-10-30-newsletter.md new file mode 100644 index 000000000..d78201984 --- /dev/null +++ b/_posts/fr/newsletters/2018-10-30-newsletter.md @@ -0,0 +1,172 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #19' +permalink: /fr/newsletters/2018/10/30/ +name: 2018-10-30-newsletter-fr +slug: 2018-10-30-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine suggère une mise à jour pour les utilisateurs de C-Lightning, décrit une discussion sur l'ordonnancement +déterministe des entrées/sorties de BIP69 sur la liste de diffusion, note que la prise en charge publique d'ASICBoost est disponible pour +les mineurs utilisant des Antminer S9, et fournit des liens vers des ressources à propos à la fois de la solution de stockage à froid +multisig basée sur HSM Subzero publiée en open source par Square et de la récente Lightning Network Residency et Hackday à New York. Sont +également inclus une sélection récente de questions-réponses de Bitcoin Stack Exchange et des descriptions de changements notables dans le +code de projets populaires d'infrastructure Bitcoin. + +## Action items + +- **Mettez à jour vers [C-Lightning 0.6.2][] :** corrige un bug où le nœud envoyait à ses pairs un nombre excessif d'annonces de mise à jour + à propos de canaux morts. + +## Nouvelles + +- **Discussion sur [BIP69][] :** ce BIP de 2015 adopté par plusieurs portefeuilles notables spécifie une méthode optionnelle pour ordonner + de façon déterministe les entrées et sorties au sein d'une transaction sur la base du contenu public de la transaction. Cependant, + d'autres portefeuilles ne l'ont pas adopté (ou l'ont même rejeté comme inadapté à l'adoption), menant peut-être à une situation du « pire + des deux mondes » où les portefeuilles utilisant BIP69 peuvent être identifiés assez facilement et où les portefeuilles n'utilisant pas + BIP69 peuvent également être plus faciles à identifier par négation. + + Dans ce [fil][bip69 thread] sur la liste de diffusion Bitcoin-Dev, Ryan Havar suggère qu'une raison pour laquelle les auteurs de + portefeuilles aiment BIP69 est que son ordonnancement déterministe rend simple et rapide pour leurs tests de s'assurer qu'ils n'ont + divulgué aucune information à propos de la source de leurs entrées ou de la destination de leurs sorties (par ex. dans certains anciens + portefeuilles, la première sortie allait toujours au destinataire et la seconde sortie était toujours la monnaie---rendant le suivi des + pièces trivial). Havar suggère ensuite un ordonnancement déterministe alternatif fondé sur des informations privées qui seraient + disponibles pour la suite de tests mais non exposées par les portefeuilles en production, permettant aux développeurs qui veulent + contrecarrer l'analyse de la chaîne de blocs---tout en ayant aussi des tests simples et rapides---de s'éloigner de BIP69. + +- **Prise en charge d'ASICBoost manifeste pour les mineurs S9 :** la prise en charge de cette fonctionnalité améliorant l'efficacité a été + annoncée cette semaine à la fois par [Bitmain][bitmain oab] et [Braiins][braiins oab]. ASICBoost tire parti du fait que l'algorithme + SHA256 utilisé dans le minage de Bitcoin découpe d'abord l'en-tête de bloc de 80 octets en segments de 64 octets. Si un mineur peut + trouver plusieurs en-têtes de blocs proposés où le premier segment de 64 octets est différent mais où le début du segment suivant de 64 + octets est identique, alors il peut essayer différentes combinaisons du premier segment et du second segment afin de réduire le nombre + total d'opérations de hachage qu'il doit effectuer pour trouver un bloc valide. Les premières estimations indiquent une amélioration de 10 + % (ou peut-être davantage) sur le matériel Antminer S9 existant. + + La forme manifeste d'ASICBoost modifie le champ versionbits dans l'en-tête de bloc, ce qui peut amener des programmes comme Bitcoin Core à + afficher un avertissement tel que « 13 of last 100 blocks have unexpected version ». Certains mineurs ASICBoost ont volontairement + restreint leur plage modifiée de versionbits à celle définie par [BIP320][], donnant aux futurs programmes l'option d'ignorer ces bits + pour la signalisation de mise à niveau. + +- **Solution de stockage à froid multisig basée sur HSM publiée en open source :** [Square][] a publié le code et la documentation de la + solution de stockage à froid qu'ils ont mise en œuvre pour protéger les dépôts des clients, ainsi qu'un outil CLI pour auditer les soldes + de portefeuilles HD à des moments arbitraires dans le temps. Optech n'a pas évalué leur solution, mais nous pouvons recommander aux + parties intéressées de lire l'excellent [article de blog][subzero blog] de Square et de visiter les dépôts de la solution de stockage à + froid [Subzero][] et de l'outil d'audit [Beancounter][]. + +- **Lightning Residency et Hackday :** la semaine dernière, [Chaincode Labs][] a accueilli un programme de cinq jours [Lightning Network + Residency][] pour aider à intégrer des développeurs à ce protocole naissant. À la suite de cela, Fulmo a organisé son quatrième [Lightning + Network Hackday][] (en réalité deux jours) également à New York, avec quelques discours, de nombreuses démos et beaucoup de hacking. + + Pierre Rochard a rédigé des résumés de toutes les présentations données lors du programme residency ([jour 1][lr1], [jour 2][lr2], [jour + 3][lr3], [jour 4][lr4]) et les vidéos des présentations devraient être publiées prochainement. Les vidéos du hackday sont déjà disponibles + : [jour 1][hd1], [jour 2][hd2]. + +## Questions et réponses sélectionnées de Bitcoin Stack Exchange + +{% comment %}{% endcomment %} + +*[Bitcoin Stack Exchange][bitcoin.se] est l'un des premiers endroits où les contributeurs d'Optech cherchent des réponses à leurs +questions---ou quand nous avons quelques moments libres pour aider les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous +mettons en lumière certaines des questions et réponses les mieux votées postées depuis notre dernière mise à jour.* + +- [Est-ce que l'utilisation du pruning rend la synchronisation initiale du nœud plus rapide ?][bse 79592] L'élagage des blocs après leur + traitement peut réduire les besoins en espace disque de plus de 97 % à l'heure actuelle, mais accélère-t-il aussi la synchronisation ? Le + développeur Bitcoin Core Gregory Maxwell répond. + +- [Quelqu'un peut-il vous voler en fermant son canal de paiement Lightning Network d'une certaine manière ?][bse 80399] Plusieurs + différentes façons de fermer un canal de paiement Lightning Network sont décrites, et le développeur C-Lightning Christian Decker explique + comment un programme suivant le protocole LN protégera votre argent dans chaque cas. + +- [Combien d'énergie faut-il pour créer un bloc ?][bse 79691] Nate Eldredge fournit une formule simple et un ensemble de liens vers des + données que n'importe qui peut utiliser pour estimer la quantité moyenne d'énergie nécessaire pour générer un bloc au niveau de difficulté + actuel. Pour la difficulté actuelle en utilisant uniquement des Antminer S9 sans ASICBoost, un bloc moyen consomme 841 629 kilowattheures + (kWh). À une estimation courante de 0,04 $/kWh, cela représente environ 34 000 $ d'électricité---bien en dessous de la subvention de bloc + actuelle d'environ 80 000 $---mais en utilisant [l'estimation récente d'AJ Towns][towns mining estimate] de 0,16 $/kWh qui inclut des + coûts au-delà de l'électricité et tente de prendre en compte des primes de risque, le coût estimé d'un bloc est d'environ 135 000 $. + +## Notable merges + +*Changements notables dans le code cette semaine dans [Bitcoin Core][bitcoin core repo], [LND][lnd repo], [C-lightning][core lightning +repo], et [libsecp256k1][libsecp256k1 repo].* + +{% comment %}{% endcomment %} + +- [Bitcoin Core #14451][] permet de compiler optionnellement Bitcoin-Qt sans prise en charge du protocole de paiement [BIP70][] et ajoute un + avertissement de dépréciation indiquant que la prise en charge par défaut pourrait être supprimée dans une future version. Le PDG de + BitPay, qui est le plus grand utilisateur de BIP70 (mais qui veut utiliser une version différente du protocole), a [indiqué][bitpay bip70 + comment] qu'il soutenait la suppression de BIP70 par Bitcoin Core. Les développeurs semblent favorables à la suppression du protocole pour + des raisons de sécurité et parce que son utilisation est en déclin. La dépendance de BIP70 à OpenSSL a entraîné la publication en urgence + de [Bitcoin Core 0.9.1][] en 2014 à la suite de la [vulnérabilité Heartbleed][], et il est prévu que sa suppression éliminera le risque de + vulnérabilités similaires à l'avenir. + +- [Bitcoin Core #14296][] supprime la RPC `addwitnessaddress`, devenue obsolète. Cette RPC a été ajoutée dans la version 0.13.0 pour + permettre de tester segwit sur regtest et testnet avant son activation sur mainnet et son intégration dans le portefeuille. Depuis la + version 0.16.0, le portefeuille de Bitcoin Core prend en charge l'obtention directe d'adresses en utilisant le mécanisme habituel + [getnewaddress][rpc getnewaddress]. + +- [Bitcoin Core #14468][] déprécie la RPC `generate`. Cette méthode génère de nouveaux blocs en mode regtest, mais elle nécessite d'obtenir + de nouvelles adresses à partir du portefeuille intégré de Bitcoin Core afin de leur verser la [récompense de bloc][term block reward] du + minage. Une méthode de remplacement, [generatetoaddress][rpc generatetoaddress], a été introduite dans la version 0.13.0, ce qui permet à + n'importe quel portefeuille regtest de générer une adresse qui recevra la récompense de bloc. Cela fait partie d'un effort continu pour + permettre au plus grand nombre possible de RPC de fonctionner sans le portefeuille afin d'améliorer la couverture de test des nœuds sans + portefeuille ainsi que de faciliter une future transition possible vers une séparation complète du portefeuille et du nœud. + +- [Bitcoin Core #14150][] ajoute la prise en charge de l'[origine de clé][] aux [descripteurs de scripts de sortie][output script + descriptors]. En plus de vous permettre de passer un argument supplémentaire à la RPC [scantxoutset][rpc scantxoutset], cela n'ajoute + actuellement aucune fonctionnalité à Bitcoin Core---mais cela permettra d'utiliser l'origine de clé avec les PSBT [BIP174][] et les + portefeuilles en surveillance seule lorsque ces parties du logiciel auront été mises à jour pour utiliser des descripteurs. Voir les + bulletins [#5][le bulletin #5], [#7][le bulletin #7], [#9][le bulletin #9], [#12][le bulletin #12], et [#17][le bulletin #17] pour les + précédentes discussions sur les descripteurs de scripts de sortie. La prise en charge de l'origine de clé permet d'utiliser des clés + publiques étendues qui ont été exportées depuis un portefeuille HD utilisant la dérivation renforcée [BIP32][] pour protéger les clés + privées ancêtres, ce qui aide à rendre les descripteurs de scripts de sortie compatibles avec la plupart des portefeuilles matériels. + +- [LND #1981][] garantit que LND ne divulgue pas d'informations à propos de ses pairs qui ne s'annoncent pas comme nœuds publics. + +- {:#lnd-1535-1512} LND [#1535][LND #1535] et [#1512][LND #1512] ajoutent le protocole de communication côté serveur pour les watchtowers + ainsi que de nombreux tests vérifiant leur bon fonctionnement. L'utilisation correcte du protocole LN nécessite une surveillance régulière + des transactions qui sont ajoutées à la chaîne de blocs ; les watchtowers sont donc des serveurs conçus pour aider à défendre les canaux + de paiement des utilisateurs qui s'attendent à être hors ligne pendant une période prolongée. À ce titre, les watchtowers sont considérées + comme une fonctionnalité clé pour permettre une adoption plus large de LN par des utilisateurs moins avancés. Cependant, une spécification + standard pour les watchtowers n'a pas été convenue entre les multiples implémentations de LN, donc LND ne propose cette fonctionnalité que + pour des tests initiaux et en restreint l'usage au testnet. + +{% include references.md %} +{% include linkers/issues.md issues="14451,14296,14468,14150,1981,1535,1512" %} + +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} +[bse 79592]: {{bse}}79592 +[bse 80399]: {{bse}}80399 +[bse 79691]: {{bse}}79691 + +[hd1]: https://www.youtube.com/watch?v=FGxFd944jMg +[hd2]: https://www.youtube.com/watch?v=o87GVYFvwIk +[lr1]: https://medium.com/@pierre_rochard/day-1-of-the-chaincode-labs-lightning-residency-ab4c29ce2077 +[lr2]: https://medium.com/@pierre_rochard/day-2-of-the-chaincode-labs-lightning-residency-669aecab5f16 +[lr3]: https://medium.com/@pierre_rochard/day-3-of-the-chaincode-labs-lightning-residency-5a7fad88bc62 +[lr4]: https://medium.com/@pierre_rochard/day-4-of-the-chaincode-labs-lightning-residency-f28b046fc1a6 +[c-lightning 0.6.2]: https://github.com/ElementsProject/lightning/releases +[bip69 thread]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-October/016457.html +[bitmain oab]: https://blog.bitmain.com/en/new-firmware-activate-overt-asicboost-bm1387-antminer-models/ +[braiins oab]: https://twitter.com/braiins_systems/status/1055153228772503553 +[subzero blog]: https://medium.com/square-corner-blog/open-sourcing-subzero-ee9e3e071827 +[subzero]: https://github.com/square/subzero +[beancounter]: https://github.com/square/beancounter/ +[lightning network residency]: https://lightningresidency.com/ +[chaincode labs]: https://chaincode.com/ +[lightning network hackday]: https://lightninghackday.fulmo.org/ +[bitpay bip70 comment]: https://github.com/bitcoin/bitcoin/pull/14451#issuecomment-431496319 +[bitcoin core 0.9.1]: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.9.1.md +[heartbleed vulnerability]: https://bitcoin.org/en/alert/2014-04-11-heartbleed +[term block reward]: https://btcinformation.org/en/glossary/block-reward +[origine de clé]: https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82#key-origin-identification +[towns mining estimate]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/playing-with-fire-adjusting-bitcoin-block-subsidy/ +[square]: https://cash.app/bitcoin +[le bulletin #5]: /fr/newsletters/2018/07/24/#premiere-utilisation-des-descripteurs-de-scripts-de-sortie +[le bulletin #7]: /fr/newsletters/2018/08/07/#bitcoin-core-13697 +[le bulletin #9]: /en/newsletters/2018/08/21/#ameliorations-des-descripteurs-de-scripts-de-sortie +[le bulletin #12]: /fr/newsletters/2018/09/11/#bitcoin-core-14096 +[le bulletin #17]: /en/newsletters/2018/10/16/#descripteurs-de-script-et-descript +[output script descriptors]: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md From b98a4aa6d84e5bead648b737b2313dc37fcfd3ea Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Tue, 14 Apr 2026 18:01:54 +0200 Subject: [PATCH 06/12] Update 2018-10-09-newsletter.md --- _posts/fr/newsletters/2018-10-09-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/fr/newsletters/2018-10-09-newsletter.md b/_posts/fr/newsletters/2018-10-09-newsletter.md index 80a88681b..4c8f32187 100644 --- a/_posts/fr/newsletters/2018-10-09-newsletter.md +++ b/_posts/fr/newsletters/2018-10-09-newsletter.md @@ -190,7 +190,7 @@ cette avance plus souvent et une plus petite partie de leur preuve de travail es {% include references.md %} -[videos]: https://tokyo2018.scalingbitcoin.org/#remote-participation +[vidéos]: https://tokyo2018.scalingbitcoin.org/#remote-participation [transcriptions]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/ [vid subsidy]: https://youtu.be/y8hJ0VTPE34?t=39 [tx subsidy]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/playing-with-fire-adjusting-bitcoin-block-subsidy/ From 1c4fd71217bf2e8d3a084987f6a07a8942745cb4 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Tue, 14 Apr 2026 18:01:56 +0200 Subject: [PATCH 07/12] Update 2018-10-30-newsletter.md --- _posts/fr/newsletters/2018-10-30-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/fr/newsletters/2018-10-30-newsletter.md b/_posts/fr/newsletters/2018-10-30-newsletter.md index d78201984..f2e1cf3b9 100644 --- a/_posts/fr/newsletters/2018-10-30-newsletter.md +++ b/_posts/fr/newsletters/2018-10-30-newsletter.md @@ -159,7 +159,7 @@ it to write a good description, and I doubt non-LN devs care -->{% endcomment %} [lightning network hackday]: https://lightninghackday.fulmo.org/ [bitpay bip70 comment]: https://github.com/bitcoin/bitcoin/pull/14451#issuecomment-431496319 [bitcoin core 0.9.1]: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.9.1.md -[heartbleed vulnerability]: https://bitcoin.org/en/alert/2014-04-11-heartbleed +[vulnérabilité Heartbleed]: https://bitcoin.org/en/alert/2014-04-11-heartbleed [term block reward]: https://btcinformation.org/en/glossary/block-reward [origine de clé]: https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82#key-origin-identification [towns mining estimate]: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/playing-with-fire-adjusting-bitcoin-block-subsidy/ From fac99fd0d9e0b2c8e229468fc47239741dfb3036 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Wed, 15 Apr 2026 07:15:11 +0200 Subject: [PATCH 08/12] Update 2018-10-30-newsletter.md --- _posts/fr/newsletters/2018-10-30-newsletter.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/fr/newsletters/2018-10-30-newsletter.md b/_posts/fr/newsletters/2018-10-30-newsletter.md index f2e1cf3b9..dc73c5986 100644 --- a/_posts/fr/newsletters/2018-10-30-newsletter.md +++ b/_posts/fr/newsletters/2018-10-30-newsletter.md @@ -166,7 +166,7 @@ it to write a good description, and I doubt non-LN devs care -->{% endcomment %} [square]: https://cash.app/bitcoin [le bulletin #5]: /fr/newsletters/2018/07/24/#premiere-utilisation-des-descripteurs-de-scripts-de-sortie [le bulletin #7]: /fr/newsletters/2018/08/07/#bitcoin-core-13697 -[le bulletin #9]: /en/newsletters/2018/08/21/#ameliorations-des-descripteurs-de-scripts-de-sortie +[le bulletin #9]: /fr/newsletters/2018/08/21/#ameliorations-des-descripteurs-de-scripts-de-sortie [le bulletin #12]: /fr/newsletters/2018/09/11/#bitcoin-core-14096 -[le bulletin #17]: /en/newsletters/2018/10/16/#descripteurs-de-script-et-descript +[le bulletin #17]: /fr/newsletters/2018/10/16/#descripteurs-de-script-et-descript [output script descriptors]: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md From 7e9489555731c77767c44f6237c4e42d456c0225 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 25 Apr 2026 09:12:22 +0200 Subject: [PATCH 09/12] Update 2018-10-30-newsletter.md --- _posts/fr/newsletters/2018-10-30-newsletter.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/_posts/fr/newsletters/2018-10-30-newsletter.md b/_posts/fr/newsletters/2018-10-30-newsletter.md index dc73c5986..38bdbee7e 100644 --- a/_posts/fr/newsletters/2018-10-30-newsletter.md +++ b/_posts/fr/newsletters/2018-10-30-newsletter.md @@ -58,9 +58,9 @@ code de projets populaires d'infrastructure Bitcoin. Residency][] pour aider à intégrer des développeurs à ce protocole naissant. À la suite de cela, Fulmo a organisé son quatrième [Lightning Network Hackday][] (en réalité deux jours) également à New York, avec quelques discours, de nombreuses démos et beaucoup de hacking. - Pierre Rochard a rédigé des résumés de toutes les présentations données lors du programme residency ([jour 1][lr1], [jour 2][lr2], [jour - 3][lr3], [jour 4][lr4]) et les vidéos des présentations devraient être publiées prochainement. Les vidéos du hackday sont déjà disponibles - : [jour 1][hd1], [jour 2][hd2]. + Pierre Rochard a rédigé des résumés de toutes les présentations données lors du programme residency ([jour 1][lr1], [jour 2][lr2], + [jour 3][lr3], [jour 4][lr4]) et les vidéos des présentations devraient être publiées prochainement. Les vidéos du hackday sont déjà + disponibles : [jour 1][hd1], [jour 2][hd2]. ## Questions et réponses sélectionnées de Bitcoin Stack Exchange @@ -125,7 +125,8 @@ it to write a good description, and I doubt non-LN devs care -->{% endcomment %} - [LND #1981][] garantit que LND ne divulgue pas d'informations à propos de ses pairs qui ne s'annoncent pas comme nœuds publics. -- {:#lnd-1535-1512} LND [#1535][LND #1535] et [#1512][LND #1512] ajoutent le protocole de communication côté serveur pour les watchtowers +- {:#lnd-1535-1512} + LND [#1535][LND #1535] et [#1512][LND #1512] ajoutent le protocole de communication côté serveur pour les watchtowers ainsi que de nombreux tests vérifiant leur bon fonctionnement. L'utilisation correcte du protocole LN nécessite une surveillance régulière des transactions qui sont ajoutées à la chaîne de blocs ; les watchtowers sont donc des serveurs conçus pour aider à défendre les canaux de paiement des utilisateurs qui s'attendent à être hors ligne pendant une période prolongée. À ce titre, les watchtowers sont considérées @@ -166,7 +167,7 @@ it to write a good description, and I doubt non-LN devs care -->{% endcomment %} [square]: https://cash.app/bitcoin [le bulletin #5]: /fr/newsletters/2018/07/24/#premiere-utilisation-des-descripteurs-de-scripts-de-sortie [le bulletin #7]: /fr/newsletters/2018/08/07/#bitcoin-core-13697 -[le bulletin #9]: /fr/newsletters/2018/08/21/#ameliorations-des-descripteurs-de-scripts-de-sortie +[le bulletin #9]: /fr/newsletters/2018/08/21/#descripteurs-de-script-et-descript-script-descriptors-and-descript [le bulletin #12]: /fr/newsletters/2018/09/11/#bitcoin-core-14096 [le bulletin #17]: /fr/newsletters/2018/10/16/#descripteurs-de-script-et-descript [output script descriptors]: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md From 90e07bca97e0e39c4228047443a5c7e1f8d5c909 Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Mon, 27 Apr 2026 16:21:23 +0200 Subject: [PATCH 10/12] Update 2018-10-30-newsletter.md --- _posts/fr/newsletters/2018-10-30-newsletter.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/fr/newsletters/2018-10-30-newsletter.md b/_posts/fr/newsletters/2018-10-30-newsletter.md index 38bdbee7e..07f9c924b 100644 --- a/_posts/fr/newsletters/2018-10-30-newsletter.md +++ b/_posts/fr/newsletters/2018-10-30-newsletter.md @@ -167,7 +167,7 @@ it to write a good description, and I doubt non-LN devs care -->{% endcomment %} [square]: https://cash.app/bitcoin [le bulletin #5]: /fr/newsletters/2018/07/24/#premiere-utilisation-des-descripteurs-de-scripts-de-sortie [le bulletin #7]: /fr/newsletters/2018/08/07/#bitcoin-core-13697 -[le bulletin #9]: /fr/newsletters/2018/08/21/#descripteurs-de-script-et-descript-script-descriptors-and-descript +[le bulletin #9]: /fr/newsletters/2018/08/21/#ameliorations-des-descripteurs-de-scripts-de-sortie [le bulletin #12]: /fr/newsletters/2018/09/11/#bitcoin-core-14096 -[le bulletin #17]: /fr/newsletters/2018/10/16/#descripteurs-de-script-et-descript +[le bulletin #17]: /fr/newsletters/2018/10/16/#descripteurs-de-script-et-descript-script-descriptors-and-descript [output script descriptors]: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md From 15614655e10e5a9c74e1a9d9f787d2180d5eb69f Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 2 May 2026 10:05:49 +0200 Subject: [PATCH 11/12] Update 2018-10-09-newsletter.md --- _posts/fr/newsletters/2018-10-09-newsletter.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/_posts/fr/newsletters/2018-10-09-newsletter.md b/_posts/fr/newsletters/2018-10-09-newsletter.md index 4c8f32187..e4f822b84 100644 --- a/_posts/fr/newsletters/2018-10-09-newsletter.md +++ b/_posts/fr/newsletters/2018-10-09-newsletter.md @@ -1,5 +1,5 @@ --- -title: 'Bulletin Hebdomadaire Bitcoin Optech #16' +title: 'Bulletin Hebdomadaire Bitcoin Optech #16 : Spécial Scaling Bitcoin' permalink: /fr/newsletters/2018/10/09/ name: 2018-10-09-newsletter-fr slug: 2018-10-09-newsletter-fr @@ -172,11 +172,12 @@ liées au contenu de ce bulletin. Toute erreur restante est entièrement de la f ## Notes de bas de page -[^freq-pow-waste]: Lorsqu'un mineur crée un nouveau bloc à la pointe de la chaîne, il peut commencer à travailler immédiatement sur le bloc -suivant---mais tous les autres mineurs travaillent encore sur un ancien bloc jusqu'à ce qu'ils reçoivent le nouveau bloc, ce qui signifie -que leur preuve de travail pendant cette brève période est gaspillée (elle n'augmente ni la sécurité du réseau ni ne fournit aux mineurs une -compensation financière). Les mineurs disposant de plus de taux de hachage produisent davantage de blocs en moyenne, ils obtiennent donc -cette avance plus souvent et une plus petite partie de leur preuve de travail est gaspillée. +[^freq-pow-waste]: + Lorsqu'un mineur crée un nouveau bloc à la pointe de la chaîne, il peut commencer à travailler immédiatement sur le bloc + suivant---mais tous les autres mineurs travaillent encore sur un ancien bloc jusqu'à ce qu'ils reçoivent le nouveau bloc, ce qui signifie + que leur preuve de travail pendant cette brève période est gaspillée (elle n'augmente ni la sécurité du réseau ni ne fournit aux mineurs une + compensation financière). Les mineurs disposant de plus de taux de hachage produisent davantage de blocs en moyenne, ils obtiennent donc + cette avance plus souvent et une plus petite partie de leur preuve de travail est gaspillée. Pour deux mineurs parfaitement équitables séparés par la moitié du globe, le délai réseau pratique minimal entre eux est d'environ 0,2 seconde, ce qui signifie qu'un petit mineur éloigné de la plupart des autres mineurs n'est probablement productif que pendant 599,8 From c820b2f7bc7fb7aa2241c6d47bf40c81c3a4e1ea Mon Sep 17 00:00:00 2001 From: Copinmalin Date: Sat, 2 May 2026 10:13:21 +0200 Subject: [PATCH 12/12] Update 2018-10-09-newsletter.md --- _posts/fr/newsletters/2018-10-09-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/fr/newsletters/2018-10-09-newsletter.md b/_posts/fr/newsletters/2018-10-09-newsletter.md index e4f822b84..ead685727 100644 --- a/_posts/fr/newsletters/2018-10-09-newsletter.md +++ b/_posts/fr/newsletters/2018-10-09-newsletter.md @@ -172,7 +172,7 @@ liées au contenu de ce bulletin. Toute erreur restante est entièrement de la f ## Notes de bas de page -[^freq-pow-waste]: +[^freq-pow-waste]: Lorsqu'un mineur crée un nouveau bloc à la pointe de la chaîne, il peut commencer à travailler immédiatement sur le bloc suivant---mais tous les autres mineurs travaillent encore sur un ancien bloc jusqu'à ce qu'ils reçoivent le nouveau bloc, ce qui signifie que leur preuve de travail pendant cette brève période est gaspillée (elle n'augmente ni la sécurité du réseau ni ne fournit aux mineurs une