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 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..4c8f32187 --- /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 %} + +[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/ +[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 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 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 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..dc73c5986 --- /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 +[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/ +[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 #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