diff --git a/_posts/fr/newsletters/2018-09-04-newsletter.md b/_posts/fr/newsletters/2018-09-04-newsletter.md new file mode 100644 index 000000000..ca14b71b8 --- /dev/null +++ b/_posts/fr/newsletters/2018-09-04-newsletter.md @@ -0,0 +1,94 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #11' +permalink: /fr/newsletters/2018/09/04/ +name: 2018-09-04-newsletter-fr +slug: 2018-09-04-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine comprend un rappel vous invitant à aider à tester la version candidate de la prochaine version de Bitcoin Core, +des informations sur le développement du nouveau tableau de bord public d'Optech, des résumés de deux discussions sur la liste de diffusion +Bitcoin-Dev, et des commits notables de projets d'infrastructure Bitcoin. + +## Éléments d'action + +- **Consacrez du temps à tester Bitcoin Core 0.17RC2 :** Bitcoin Core a téléversé les [binaires][bcc 0.17] pour la Release Candidate (RC) 2 + de la version 0.17. Les tests sont grandement appréciés et peuvent aider à assurer la qualité de la version finale. + +## Éléments du tableau de bord + +- **Tableau de bord Optech :** un [article de blog][dashboard post] de Marcin Jachymiak présente le tableau de bord en direct qu'il a + développé pour Optech pendant son stage cet été, fournissant non seulement un aperçu des informations que le tableau de bord met à votre + disposition, mais aussi une description de la manière dont il l'a construit pour toute personne souhaitant répliquer indépendamment les + données ou étendre autrement le tableau de bord en utilisant son propre nœud complet. + + Le reste de l'équipe Optech remercie Marcin pour son travail dévoué et sa perspicacité, et nous lui souhaitons le meilleur pour l'année à + venir. + +## Nouvelles + +- **Discussion sur la réinitialisation de testnet :** le premier réseau de test public de Bitcoin a été introduit fin 2010 ; quelques mois + plus tard, il a été réinitialisé en testnet2 ; puis de nouveau réinitialisé vers l'actuel testnet3 à la mi-2012. Aujourd'hui, testnet3 + compte plus de 1,4 million de blocs et consomme plus de 20 Go d'espace disque sur les nœuds d'archivage. Une [discussion][testnet reset] a + été lancée sur la liste de diffusion Bitcoin-Dev au sujet d'une nouvelle réinitialisation de testnet afin de fournir une chaîne plus + petite pour l'expérimentation. En plus de la discussion sur le fait de savoir s'il est bon ou non d'avoir une grande chaîne de test pour + l'expérimentation, il a également été [suggéré][signed testnet] qu'un futur testnet pourrait vouloir utiliser des blocs signés au lieu de + la preuve de travail afin de permettre à la chaîne de fonctionner de manière plus prévisible que l'actuel testnet3, qui est sujet à de + fortes oscillations du taux de hachage. Cela permettrait aussi une gestion facile des exercices de crise sur testnet, tels que de grandes + réorganisations de chaîne. + +- **Mises à jour proposées de sighash :** avant de signer une transaction, un portefeuille Bitcoin crée un hachage cryptographique de la + transaction non signée et de certaines autres données. Ensuite, au lieu de signer directement la transaction, le portefeuille signe ce + hachage. Depuis l'implémentation originelle 0.1 de Bitcoin, les portefeuilles sont autorisés à retirer certaines parties de la transaction + non signée du hachage avant de la signer, ce qui permet à ces parties de la transaction d'être modifiées par d'autres personnes telles que + d'autres participants à un contrat multipartite. + + Dans [BIP143][], segwit a conservé tous les drapeaux de hachage de signature (sighash) originaux de Bitcoin 0.1, mais a apporté quelques + changements mineurs (mais utiles) aux données que les portefeuilles incluent dans le hachage, ce qui a rendu plus difficile pour les + mineurs de mener des attaques DoS contre d'autres mineurs et ce qui a facilité pour des appareils peu puissants tels que les portefeuilles + matériels la protection des fonds des utilisateurs. Cette semaine, le co-auteur de BIP143, Johnson Lau, a [publié][sighash changes] + quelques changements suggérés aux drapeaux sighash, y compris de nouveaux drapeaux, qui pourraient être implémentés sous forme de soft + fork en utilisant le mécanisme de mise à jour des scripts witness fourni dans le cadre de segwit. + + {% comment %}{% endcomment %} + + Si les changements sont adoptés, certains des avantages notables incluent : le fait de faciliter la participation sécurisée des + portefeuilles matériels à des transactions de type CoinJoin ainsi qu'à d'autres contrats intelligents, une possible + augmentation plus facile des frais par n'importe quelle partie individuelle dans une transaction multipartite, et l'empêchement + pour des contreparties et des tierces parties à des contrats intelligents sophistiqués de gonfler la taille des transactions multipartites + dans le cadre d'une attaque DoS qui réduit la priorité des frais d'une transaction. + +## Commits notables + +*Commits notables cette semaine dans [Bitcoin Core][bitcoin core repo], [LND][lnd repo], et [C-lightning][core lightning repo]. Rappel : les +nouvelles fusions dans Bitcoin Core sont effectuées sur sa branche de développement master et ont peu de chances de faire partie de la +prochaine version 0.17---vous devrez probablement attendre la version 0.18 dans environ six mois à partir de maintenant.* + +{% comment %}{% endcomment %} + +- [Bitcoin Core #12952][] : après avoir été déprécié pendant plusieurs versions majeures et désactivé par défaut dans la prochaine version + 0.17, le système de comptes intégré de Bitcoin Core a été supprimé de la branche de développement master. Le système de comptes a été + ajouté fin 2010 pour permettre à une première plateforme d'échange Bitcoin de gérer ses comptes utilisateurs dans Bitcoin Core, mais il + manquait de nombreuses fonctionnalités souhaitables pour de véritables systèmes de production (comme les mises à jour atomiques de base de + données) et il perturbait souvent les utilisateurs ; sa suppression progressive et propre est donc un objectif depuis plusieurs années. + +- [Bitcoin Core #13987][] : lorsque Bitcoin Core reçoit une transaction dont les frais par vbyte sont inférieurs à son taux de frais + minimal, il ignore cette transaction. [BIP133][] (implémenté dans Bitcoin Core 0.13.0) permet à un nœud d'indiquer à ses pairs quel est + son taux de frais minimal afin que ces pairs ne gaspillent pas de bande passante en envoyant des transactions qui seront ignorées. Cette + PR fournit désormais cette information pour chaque pair dans la RPC [getpeerinfo][rpc getpeerinfo] en utilisant la nouvelle valeur + `minfeefilter`, vous permettant de découvrir facilement les taux de frais minimaux utilisés par vos pairs. + +- [C-Lightning #1887][] permet désormais de demander à lightningd de calculer un objectif de taux de frais pour vos transactions on-chain en + passant soit "urgent", "normal", ou "slow" au paramètre `feerate`. Alternativement, vous pouvez utiliser ce paramètre pour spécifier + manuellement un taux de frais particulier que vous souhaitez utiliser. + +{% include references.md %} +{% include linkers/issues.md issues="12952,13987,1887" %} + +[bcc 0.17]: https://bitcoincore.org/bin/bitcoin-core-0.17.0/ +[dashboard post]: /en/dashboard-announcement/ +[testnet reset]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016337.html +[signed testnet]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016348.html +[sighash changes]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016345.html diff --git a/_posts/fr/newsletters/2018-09-11-newsletter.md b/_posts/fr/newsletters/2018-09-11-newsletter.md new file mode 100644 index 000000000..4639e4e99 --- /dev/null +++ b/_posts/fr/newsletters/2018-09-11-newsletter.md @@ -0,0 +1,80 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #12' +permalink: /fr/newsletters/2018/09/11/ +name: 2018-09-11-newsletter-fr +slug: 2018-09-11-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine fait référence à une discussion sur le chiffrement BIP151 pour le protocole réseau pair à pair, fournit une +mise à jour sur la compatibilité entre Bitcoin et le projet de spécification W3C Web Payments, et décrit brièvement quelques fusions +notables dans des projets populaires d'infrastructure Bitcoin. + +## Actions requises + +- **Allouer du temps pour tester Bitcoin Core 0.17RC3 :** Bitcoin Core a téléversé des [binaires][bcc 0.17] pour la version candidate (RC) 3 + de 0.17. Les tests sont grandement appréciés et peuvent aider à assurer la qualité de la version finale. + +- Les plans pour le deuxième [atelier][workshop] Optech progressent, avec la date et le lieu confirmés à Paris les 12 et 13 novembre. La + liste provisoire des sujets est : + - Replace-by-fee contre child-pays-for-parent comme techniques de remplacement de frais + - Transactions Bitcoin partiellement signées (BIP 174) + - Descripteurs de scripts de sortie pour l'interopérabilité des portefeuilles (gist) + - Intégration de portefeuilles Lightning et applications pour les plateformes d'échange + - Approches de sélection et de consolidation des pièces + + **Les entreprises membres qui souhaiteraient envoyer des ingénieurs à l'atelier devraient [envoyer un courriel à Optech][optech email]**. + +## Nouvelles + +- **Discussion BIP151 :** comme mentionné dans le [Bulletin #10][news10 news], Jonas Schnelli a [proposé][schnelli bip151] une version + préliminaire mise à jour du chiffrement [BIP151][] pour le protocole réseau pair à pair. Le cryptographe Tim Ruffing a fourni une + [critique constructive][ruffing bip151] du projet sur la liste de diffusion Bitcoin-Dev cette semaine, qui a également reçu des + réfutations tout aussi constructives de la part de Schnelli et Gregory Maxwell. Ces messages peuvent être intéressants à lire pour toute + personne se demandant pourquoi certains choix cryptographiques ont été faits dans le protocole, comme l'utilisation de l'échange de clés + NewHope résistant à l'informatique quantique. + +- **Mise à jour du groupe de travail W3C Web Payments :** le développeur du Lightning Network Christian Decker est membre de ce groupe qui + tente de créer des standards pour les paiements sur le web. Dans une [réponse][decker w3c] envoyée à la liste de diffusion Lightning-Dev, + Decker explique pourquoi il pense que la version préliminaire actuelle de la spécification sera fondamentalement compatible à la fois avec + les paiements vers des adresses Bitcoin et les paiements Lightning Network. Le projet attribue même explicitement le code de devise XBT à + Bitcoin. + +## Fusions notables + +*Fusions notables cette semaine dans [Bitcoin Core][bitcoin core repo], [LND][lnd repo] et [C-lightning][core lightning repo]. Rappel : les +nouvelles fusions dans Bitcoin Core sont faites sur sa branche de développement master et ont peu de chance de faire partie de la prochaine +version 0.17---vous devrez probablement attendre la version 0.18 dans environ six mois à partir de maintenant.* + +- [Bitcoin Core #12775][] ajoute la prise en charge de RapidCheck (une réimplémentation de [QuickCheck][]) à Bitcoin Core, fournissant une + suite de tests basée sur les propriétés qui génère ses propres tests à partir de ce que les programmeurs lui indiquent être les propriétés + d'une fonction (par ex. ce qu'elle accepte en entrée et renvoie en sortie). + +- [Bitcoin Core #12490][] supprime la RPC `signrawtransaction` de la branche de développement master. Cette RPC est étiquetée comme obsolète + dans la prochaine version 0.17 et les utilisateurs sont encouragés à utiliser la RPC `signrawtransactionwithkey` lorsqu'ils fournissent + leur propre clé privée pour la signature, ou la RPC `signrawtransactionwithwallet` lorsqu'ils veulent que le portefeuille intégré + fournisse automatiquement la clé privée. + +- [Bitcoin Core #14096][] fournit une [documentation pour les descripteurs de scripts de sortie][] qui sont utilisés dans la nouvelle RPC + `scantxoutset` de Bitcoin Core 0.17 et dont l'utilisation est prévue pour d'autres interactions avec le portefeuille à l'avenir. + +- **LND** a effectué près de 30 fusions la semaine passée, dont beaucoup ont apporté de petites améliorations ou corrections de bugs à sa + fonctionnalité d'autopilotage---sa capacité à permettre aux utilisateurs de choisir d'ouvrir automatiquement de nouveaux canaux avec des + pairs sélectionnés automatiquement. Plusieurs fusions ont également mis à jour les versions des bibliothèques dont LND dépend. + +- [C-Lightning #1899][] a ajouté plusieurs centaines de lignes de documentation à son dépôt cette semaine, pour la plupart de la + documentation de code en ligne ou des mises à jour de fichiers dans son [répertoire /doc][c-lightning docs]. + +{% include references.md %} +{% include linkers/issues.md issues="12775,12490,14096,1899" %} + +[bcc 0.17]: https://bitcoincore.org/bin/bitcoin-core-0.17.0/ +[workshop]: /en/workshops +[documentation for output script descriptors]: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md +[news10 news]: /fr/newsletters/2018/08/28/#pr-ouverte-pour-le-support-initial-de-bip151 +[decker w3c]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001404.html +[schnelli bip151]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016355.html +[ruffing bip151]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016372.html +[quickcheck]: https://en.wikipedia.org/wiki/QuickCheck +[c-lightning docs]: https://github.com/ElementsProject/lightning/tree/master/doc diff --git a/_posts/fr/newsletters/2018-09-18-newsletter.md b/_posts/fr/newsletters/2018-09-18-newsletter.md new file mode 100644 index 000000000..991b1b8e5 --- /dev/null +++ b/_posts/fr/newsletters/2018-09-18-newsletter.md @@ -0,0 +1,133 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #13' +permalink: /fr/newsletters/2018/09/18/ +name: 2018-09-18-newsletter-fr +slug: 2018-09-18-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine comprend des éléments d'action liés à la publication de sécurité de Bitcoin Core 0.16.3 et de Bitcoin Core +0.17RC4, au BIP322 nouvellement proposé, et au prochain atelier parisien d'Optech ; un lien vers la version 0.6.1 de C-Lightning, plus +d'informations sur BIP322, et quelques détails sur la proposition Bustapay ; ainsi que de brèves descriptions de fusions notables dans des +projets populaires d'infrastructure Bitcoin. + +## Action items + +- **Mettez à niveau vers Bitcoin Core 0.16.3 pour corriger une vulnérabilité de déni de service :** un bogue introduit dans Bitcoin Core + 0.14.0 et affectant toutes les versions suivantes jusqu'à 0.16.2 provoquera le plantage de Bitcoin Core lorsqu'il tente de valider un bloc + contenant une transaction qui tente de dépenser la même entrée deux fois. De tels blocs seraient invalides et ne peuvent donc être créés + que par des mineurs prêts à perdre le revenu autorisé provenant de la création d'un bloc (au moins 12.5 XBT ou 80 000 USD). + + Des correctifs pour les branches [master][dup txin master] et [0.16][dup txin 0.16] ont été soumis hier à l'examen public, la version + 0.16.3 a été étiquetée en contenant le correctif, et les binaires seront disponibles au [téléchargement][core download] dès qu'un nombre + suffisant de contributeurs bien connus auront reproduit la compilation déterministe---probablement plus tard aujourd'hui (mardi). Une mise + à niveau immédiate est fortement recommandée. + +- **Consacrez du temps au test de Bitcoin Core 0.17RC4 :** Bitcoin Core va bientôt téléverser les [binaires][bcc 0.17] pour la version + candidate (RC) 4 de 0.17 contenant le même correctif pour la vulnérabilité DoS décrite ci-dessus. Tous les testeurs des précédentes + versions candidates devraient mettre à niveau. Les tests sont grandement appréciés et peuvent aider à garantir la qualité de la version + finale. + +- **Examinez la proposition BIP322 pour la signature générique de messages :** ce BIP [récemment proposé][BIP322 proposal] permettra aux + utilisateurs de créer des messages signés pour tous les types d'adresses Bitcoin actuellement utilisés, y compris P2PKH, P2SH, + P2SH-wrapped segwit, P2WPKH et P2WSH. Il a le potentiel de devenir une norme de l'industrie qui sera implémentée par presque tous les + portefeuilles et pourra être utilisée par de nombreux services (tels que les places de marché pair à pair) ainsi que pour le support + client, donc Optech encourage à allouer du temps d'ingénierie pour s'assurer que la proposition est compatible avec les besoins de votre + organisation. Voir la section Nouvelles ci-dessous pour des détails supplémentaires. + +- **[Atelier parisien d'Optech][workshop] les 12-13 novembre :** les entreprises membres devraient [nous envoyer un e-mail][optech email] + pour réserver des places pour vos ingénieurs. Les sujets prévus incluent une comparaison de deux méthodes pour augmenter les frais de + transaction, une discussion sur les transactions Bitcoin partiellement signées ([BIP174][]), une introduction aux descripteurs de scripts + de sortie, des suggestions pour l'intégration de portefeuilles Lightning Network, et des approches pour une sélection efficace des pièces + (y compris la consolidation de sorties). + +## Nouvelles + +- **C-Lightning 0.6.1 publié :** cette mise à jour mineure apporte plusieurs améliorations, notamment « moins de paiements bloqués, un + meilleur routage, moins de fermetures intempestives, et plusieurs bogues agaçants corrigés. » L'[annonce de publication][c-lightning + 0.6.1] contient des détails et des liens de téléchargement. + +- **Format générique de message signé BIP322 :** depuis 2011, les utilisateurs de nombreux portefeuilles ont la possibilité de signer un + message arbitraire en utilisant la clé publique associée à une adresse P2PKH dans leur portefeuille. Cependant, il n'existe pas de moyen + standardisé pour les utilisateurs de faire de même avec une adresse P2SH ou avec n'importe lequel des différents types d'adresses segwit + (bien qu'il existe certaines [méthodes non standard][trezor p2wpkh message signing] implémentées avec des fonctionnalités limitées). + Reprenant une discussion de la liste de diffusion Bitcoin-Dev datant de plusieurs mois, Karl-Johan Alm a [proposé][BIP322 proposal] un BIP + qui pourrait fonctionner pour n'importe quelle adresse (bien qu'il ne soit pas encore décrit comment cela fonctionnerait pour les adresses + P2SH ou P2WSH impliquant un verrouillage temporel OP_CLTV ou OP_CSV). + + Le mécanisme de base est que le ou les dépensiers autorisés pour une adresse génèrent des scriptSigs et des données witness (y compris + leurs signatures) de manière très similaire à ce qu'ils feraient s'ils dépensaient les fonds---sauf qu'au lieu de signer la transaction de + dépense, ils signent leur message arbitraire à la place (plus quelques données supplémentaires prédéterminées pour s'assurer qu'ils ne + peuvent pas être piégés pour signer une transaction réelle). Le logiciel du vérificateur valide ensuite ces informations de la même + manière qu'il le ferait pour déterminer si une transaction de dépense était valide. Cela permet au mécanisme de signature de messages + d'être exactement aussi flexible que les scripts Bitcoin eux-mêmes. + + Actuellement, la discussion semble être la plus active sur la [pull request][BIP322 PR] de la proposition BIP. + +- **Discussion sur Bustapay :** alternative simplifiée au protocole proposé Pay-to-Endpoint (P2EP) [décrit dans le bulletin n°8][news8 + news], Bustapay offre une meilleure confidentialité à la fois pour les dépensiers et les destinataires---et permet également aux + destinataires d'accepter des paiements sans augmenter le nombre de leurs sorties dépensables, une forme de consolidation automatique + d'UTXO. Bien que [proposée][bustapay proposal] à la liste de diffusion Bitcoin-Dev il y a quelques semaines, plusieurs aspects de la + proposition ont été [discutés][bustapay sjors] cette semaine. + + Bien que P2EP et Bustapay puissent finir par n'être implémentés que par un petit nombre de portefeuilles et de services similaires au + protocole de paiement [BIP70][], il est également possible qu'ils finissent par être adoptés aussi largement que la prise en charge par + les portefeuilles des gestionnaires d'URI [BIP21][]. Même s'ils ne connaissent pas une adoption générale, leur avantage en matière de + confidentialité signifie qu'ils pourraient finir par être bien déployés parmi des utilisateurs de niche. Dans tous les cas, il peut être + utile de consacrer du temps d'ingénierie au suivi des propositions et des implémentations de preuve de concept afin de garantir que votre + organisation puisse facilement les adopter si cela est souhaitable. + +## Notable commits + +*Fusions notables cette semaine dans [Bitcoin Core][bitcoin core repo], [LND][lnd repo], et [C-lightning][core lightning repo]. Rappel : les +nouvelles fusions dans Bitcoin Core sont effectuées sur sa branche de développement master et il est peu probable qu'elles fassent partie de +la prochaine version 0.17---vous devrez probablement attendre la version 0.18 dans environ six mois à partir de maintenant.* + +- [Bitcoin Core #14054][] : cette PR empêche le nœud d'envoyer par défaut des [messages de rejet][p2p reject] du protocole pair à pair + [BIP61][]. Ces messages ont été implémentés pour permettre plus facilement aux développeurs de clients légers d'obtenir des retours sur + les problèmes de connexion et de relais de transactions. Cependant, il n'existe aucune obligation (ni aucun moyen d'imposer) que les nœuds + envoient un message de rejet ou un message de rejet exact, si bien que ces messages finissent sans doute seulement par gaspiller de la + bande passante. + + Il est recommandé que les développeurs connectent leurs clients de test à leurs propres nœuds et inspectent les journaux de leurs nœuds à + la recherche de messages d'erreur en cas de problèmes (peut-être après avoir activé la journalisation de débogage). Les utilisateurs qui + ont encore besoin d'envoyer des messages `reject` peuvent utiliser l'option de configuration `-enablebip61`, bien qu'il soit possible que + les messages `reject` soient complètement supprimés dans une version postérieure à 0.18. + +- [Bitcoin Core #7965][] : ce problème de longue date suivait la suppression du code dans le composant libbitcoin_server pour gérer le fait + que le portefeuille soit compilé ou non. Le problème a finalement été clos cette semaine par la fusion de [Bitcoin Core #14168][]. Ce + problème, ainsi qu'un certain nombre d'autres problèmes tels que [Bitcoin Core #10973][] (Refactor: separate wallet from node) et [Bitcoin + Core #14180][] (Run all tests even if wallet is not compiled) font partie d'un effort de long terme visant à désenchevêtrer le code du + portefeuille du code du serveur. Cela procure un certain nombre d'avantages, notamment une maintenance du code plus facile, de meilleures + possibilités de tester des composants individuels, et potentiellement un logiciel plus sûr si le composant portefeuille est déplacé dans + son propre processus. + +- [LND #1843][] : une option de configuration destinée uniquement aux tests (`--noencryptwallet`) a été renommée en `--noseedbackup`, a été + marquée comme obsolète, et son texte d'aide a été mis à jour et changé en texte d'avertissement majoritairement en majuscules. Les + développeurs craignent que des utilisateurs ordinaires n'activent cette option sans se rendre compte qu'elle les place à une seule panne + de perdre définitivement de l'argent. + +- [LND #1516][] : grâce à des mises à jour du démon Tor en amont, ce correctif permet à LND de créer et configurer automatiquement des + services onion v3 en plus de son automatisation v2 existante. Pour que l'automatisation fonctionne, les utilisateurs doivent déjà avoir + Tor installé et exécuté comme service. + +- [C-Lightning #1860][] : pour les tests, un proxy RPC est maintenant utilisé pour simplifier la simulation des réponses à divers appels + RPC, ce qui facilite le test de la gestion par lightningd de choses telles que les estimations de frais et les plantages de bitcoind. + +{% include references.md %} +{% include linkers/issues.md issues="14054,1843,1516,7965,14168,10973,14180,1860" %} + +[bcc 0.17]: https://bitcoincore.org/bin/bitcoin-core-0.17.0/ +[workshop]: /en/workshops +[news8 news]: /fr/newsletters/2018/08/14/#idee-de-pay-to-end-point-p2ep-proposee +[c-lightning 0.6.1]: https://github.com/ElementsProject/lightning/releases/tag/v0.6.1 +[BIP322 proposal]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016393.html +[BIP322 PR]: https://github.com/bitcoin/bips/pull/725 +[trezor p2wpkh message signing]: https://github.com/trezor/trezor-mcu/issues/169 +[bustapay proposal]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016340.html +[bustapay sjors]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016383.html +[p2p reject]: https://btcinformation.org/en/developer-reference#reject +[dup txin master]: https://github.com/bitcoin/bitcoin/pull/14247 +[dup txin 0.16]: https://github.com/bitcoin/bitcoin/pull/14249 +[core download]: https://bitcoincore.org/en/download diff --git a/_posts/fr/newsletters/2018-09-25-newsletter.md b/_posts/fr/newsletters/2018-09-25-newsletter.md new file mode 100644 index 000000000..7bfbbf545 --- /dev/null +++ b/_posts/fr/newsletters/2018-09-25-newsletter.md @@ -0,0 +1,149 @@ +--- +title: 'Bulletin Hebdomadaire Bitcoin Optech #14' +permalink: /fr/newsletters/2018/09/25/ +name: 2018-09-25-newsletter-fr +slug: 2018-09-25-newsletter-fr +type: newsletter +layout: newsletter +lang: fr +--- +Le bulletin de cette semaine comprend des actions à entreprendre et des nouvelles liées à la publication de sécurité de la semaine dernière +de Bitcoin Core 0.16.3 et Bitcoin Core 0.17RC4, des questions et réponses populaires de Bitcoin Stack Exchange au cours du mois écoulé, +ainsi que de courtes descriptions des fusions notables effectuées dans des projets d'infrastructure Bitcoin populaires. + +- **Passez à Bitcoin Core 0.16.3 pour corriger CVE-2018-17144 :** comme cela a été largement rapporté tôt vendredi (UTC), la vulnérabilité + de déni de service décrite dans le bulletin Optech de la semaine dernière est désormais connue pour permettre à des mineurs de tromper les + systèmes affectés afin qu'ils acceptent des bitcoins invalides. + + Au moment de la rédaction, on pense qu'une majorité des grands services Bitcoin et des mineurs ont effectué la mise à niveau, ce qui + garantit probablement que tout bloc exploitant le bogue sera rapidement réorganisé hors de la chaîne ayant le plus de preuve de + travail---réduisant le risque pour les clients SPV et les nœuds non mis à niveau. + + Si vous ne prévoyez pas de mettre à niveau ou si vous utilisez un client SPV, vous devriez envisager d'attendre plus de confirmations que + vous ne le faites habituellement (30 confirmations---environ 5 heures---sont une [recommandation][reorg risk recommendation] normale dans + ce type de situation, car cela laisse suffisamment de temps pour que les gens remarquent un problème et publient des avertissements). + Sinon, la mise à niveau vers l'une des versions suivantes reste fortement recommandée pour tout système, en particulier ceux qui + manipulent de l'argent : + + * [0.16.3][] (stable actuelle) + + * [0.17.0RC4][bcc 0.17] (version candidate pour la prochaine version majeure) + + * [0.15.2][] (rétroportage vers une ancienne version, peut avoir d'autres problèmes) + + * [0.14.3][] (rétroportage vers une ancienne version, peut avoir d'autres problèmes) + +- **Consacrez du temps à tester Bitcoin Core 0.17RC4 :** Bitcoin Core a téléversé des [binaires][bcc 0.17] pour la version candidate (RC) 4 + de 0.17. Les tests sont grandement appréciés et peuvent aider à garantir la qualité de la version finale. + +## Nouvelles + +- **CVE-2018-17144 :** les divulgations initiales puis ultérieures d'informations sur ce bogue ont été les seules nouvelles significatives + cette semaine. Pour plus d'informations, nous suggérons de lire les sources suivantes : + + - [Bitcoin Core full disclosure][] + + - [Original confidential report][], maintenant public + + - [Additional technical information][bse 79484] par Andrew Chow (également décrit ci-dessous) + + - [CVE-2018-17144 entry][cve-2018-17144], entrée de la National Vulnerability Database (NVE) en cours de mise à jour par Luke Dashjr + + Nous savons que plusieurs personnes très perspicaces réfléchissent actuellement au bogue, à ses causes ultimes et à d'éventuelles méthodes + pour réduire le risque de futurs bogues graves. Un lieu particulièrement approprié pour les discussions internes à Bitcoin Core sera les + réunions [CoreDev.tech][] du 8 au 10 octobre suivant la conférence Scaling Bitcoin de Tokyo. Nous prévoyons de faire un suivi avec des + liens vers toute conclusion importante qui sera publiée. + + Optech remercie le rapporteur original, Awemany, pour sa divulgation responsable, ainsi que les développeurs suivants qui ont + immédiatement pris le temps de confirmer rapidement le problème, d'y remédier et d'assurer discrètement une surveillance permanente des + tentatives d'exploitation du risque d'inflation alors non divulgué : Pieter Wuille, Gregory Maxwell, Wladimir van der Laan, Cory Fields, + Suhas Daftuar, Alex Morcos et Matt Corallo. + +## 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.* + +- [How does CVE-2018-17144 work?][bse 79484] Andrew Chow fournit une explication détaillée de la façon dont Bitcoin Core peut être planté ou + amené à accepter plusieurs dépenses de la même entrée dans les versions vulnérables à ce bogue. + +- [Why doesn't Bitcoin use UDP instead of TCP?][bse 79175] Gregory Maxwell décrit un cas où un logiciel Bitcoin important utilise déjà UDP, + puis détaille les raisons pour lesquelles la prise en charge d'UDP n'est pas implémentée dans les logiciels populaires de nœud complet. Il + conclut par une description de certains avantages potentiels qui pourraient être disponibles si la prise en charge d'UDP était + implémentée. + +- [How likely are you to get blacklisted by an exchange if you use Wasabi wallet's CoinJoin mixing?][bse 78654] L'auteur de Wasabi Wallet, + Adam Ficsor, explique que rien n'empêche les plateformes d'échange de refuser des fonds mélangés via Wasabi, mais que plusieurs + fonctionnalités de Wasabi (comme un ensemble d'anonymat requis de 100) peuvent aider à faire en sorte que le blocage des utilisateurs soit + mauvais pour les affaires. En alternative, il renvoie vers un outil qui pourrait permettre aux utilisateurs de contourner une liste noire + d'adresses. + +- [What's the minimum number for a Bitcoin private key?][bse 79472] Des réponses de Mark Erhardt et Gregory Maxwell ont été fournies à une + minute d'intervalle, mais une reformulation humoristique de la réponse de Maxwell par Nate Eldredge a plus de votes positifs que l'une ou + l'autre réponse au moment de la rédaction. + +## Commits notables + +*Commits notables cette semaine dans [Bitcoin Core][bitcoin core repo], [LND][lnd repo] et [C-lightning][core lightning repo]. Rappel : les +nouvelles fusions dans Bitcoin Core sont effectuées sur sa branche de développement master et il est peu probable qu'elles fassent partie de +la prochaine version 0.17---vous devrez probablement attendre la version 0.18 dans environ six mois.* + +- [Bitcoin Core #13152][] : lorsqu'ils sont connectés au réseau pair à pair, les nœuds partagent les adresses IP d'autres nœuds dont ils ont + entendu parler et ces adresses sont stockées dans une base de données que Bitcoin Core interroge lorsqu'il veut ouvrir une nouvelle + connexion. Cette PR ajoute une nouvelle commande RPC, `getnodeaddresses`, qui renvoie une ou plusieurs de ces adresses. Cela peut être + utile en conjonction avec des outils comme [bitcoin-submittx][]. + +- [LND #1738][] : la logique de validation des mises à jour de canaux a été déplacée vers le paquetage de routage afin qu'elle soit + disponible à la fois dans le routage (pour gérer les sessions de paiement échouées) et le gossiper (où elle était gérée auparavant). Cela + corrige le problème [#1707][LND #1707] (et implémente un cas de test pour celui-ci) qui pouvait avoir permis à un nœud de tromper l'un de + ses pairs pour lui faire croire qu'un pair différent avait eu une défaillance de routage, redirigeant ainsi potentiellement le trafic vers + le nœud malveillant. + +- [C-Lightning #1945][] fournit maintenant un outil `gossipwith` qui vous permet de recevoir le gossip d'un nœud indépendamment de + lightningd ou même d'envoyer un message au nœud distant. Cet outil est utilisé pour des tests supplémentaires du composant gossip de + lightningd. + +- [C-Lightning #1954][] est maintenant conforme aux mises à jour de [BOLT7][bolt7] en divisant l'ancien champ `flags` du RPC `listchannels` + en deux nouveaux champs : `message_flags` et `channel_flags`. Les commentaires du code et les références à [BOLT2][] et [BOLT11][] ont + également été mis à jour. + +- [C-Lightning #1905][] a considérablement étendu la documentation dans le code de son module des secrets. La documentation est + remarquablement bonne (et, par moments, assez humoristique). Voir [hsmd.c][]. Les commentaires du code documentent même d'autres + commentaires du code : + + ```c + /*~ You'll find FIXMEs like this scattered through the code.{% comment %}skip-test{% endcomment %} + * Sometimes they suggest simple improvements which someone like + * yourself should go ahead an implement. Sometimes they're deceptive + * quagmires which will cause you nothing but grief. You decide! */ + + /* FIXME: We should cache these. */{% comment %}skip-test{% endcomment %} + get_channel_seed(&c->id, c->dbid, &channel_seed); + derive_funding_key(&channel_seed, &funding_pubkey, &funding_privkey); + ``` + +- [C-Lightning #1947][] peut maintenant effectuer plusieurs requêtes en parallèle à bitcoind, accélérant les opérations sur les systèmes + lents ou sur les nœuds exécutant des opérations de longue durée. + +{% include references.md %} +{% include linkers/issues.md issues="13152,1738,1707,1945,1954,1905,1947" %} + +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} +[bse 79484]: {{bse}}79484 +[bse 79175]: {{bse}}79175 +[bse 78654]: {{bse}}78654 +[bse 79472]: {{bse}}79472 +[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 +[reorg risk recommendation]: https://btcinformation.org/en/you-need-to-know#instant +[bitcoin core full disclosure]: https://bitcoincore.org/en/2018/09/20/notice/ +[original confidential report]: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016424.html +[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/ +[coredev.tech]: https://coredev.tech/ +[hsmd.c]: https://github.com/ElementsProject/lightning/blob/master/hsmd/hsmd.c +[bitcoin-submittx]: https://github.com/laanwj/bitcoin-submittx