Ce bulletin du 8 juin 2018 était un essai de prévisualisation du bulletin Optech.

Nouvelles techniques sur Bitcoin du vendredi dernier à ce jeudi, du 1er juin au 7 juin.

Résumé

Une nouvelle version de maintenance de Bitcoin Core arrive bientôt avec un changement de politique de relais, le taux de hachage a augmenté rapidement donc cela pourrait être un bon moment pour envoyer des transactions à faibles frais, les fournisseurs de portefeuilles peuvent vouloir étudier la proposition BIP174 avant qu’elle ne soit entièrement implémentée, les filtres pour clients légers P2P font l’objet de nombreuses discussions, des retours sont demandés sur des propositions visant à modifier la sérialisation des clés privées et la manière dont les pools de minage communiquent avec leurs hacheurs, et Bitcoin Core fusionne une optimisation pour construire des arbres de Merkle jusqu’à environ 7x plus vite.

Points d’action clés

• ● Vérifier l’utilisation de l’opcode CodeSeparator : Bitcoin Core 0.16.1, dont la sortie est attendue d’ici environ la semaine prochaine, ne relaiera plus les transactions legacy (non-segwit) utilisant cet opcode. Autant que les contributeurs de Bitcoin Core le sachent, personne n’utilise cet opcode, mais si votre organisation l’utilise ou prévoit de l’utiliser, vous devriez immédiatement contacter un développeur du protocole ou un membre de l’équipe Optech dès que possible afin de les en informer. En fin de compte, il est possible que cet opcode soit supprimé du protocole Bitcoin pour les transactions legacy via un soft fork.

• ● Tester les versions candidates pour Bitcoin Core version 0.16.1. RC1 est disponible maintenant ; RC2 sera probablement disponible sous peu. Cette version contiendra des corrections de bugs particulièrement importantes pour les mineurs. Il n’y a pas de changements majeurs pour les dépensiers-récepteurs et les fournisseurs d’API, mais ils peuvent bénéficier de corrections de bugs.

Mises à jour du tableau de bord

• ● Augmentation du taux de hachage : la difficulté de minage a augmenté de presque 15 % cette semaine et les moyennes à plus court terme du taux de hachage du réseau montrent une croissance continue. Cela signifie que les blocs sont produits plus fréquemment que la normale et cela maintiendra probablement les frais de transaction bas tant que la tendance se poursuivra. C’est un bon moment pour consolider des sorties de transaction ou autrement envoyer des transactions à faibles frais.

• ● Transactions à très faibles frais : une augmentation du nombre de transactions à très faibles frais payant moins de 10 nanobitcoins par vbyte a été observée sur des nœuds avec une politique d’acceptation des transactions non par défaut (la politique par défaut consiste à rejeter les transactions payant moins de 10 nBTC/vbyte). Cela peut indiquer des portefeuilles mal configurés payant des frais trop faibles, ou cela peut indiquer que certains dépensiers pensent qu’il s’agit d’une stratégie viable pour économiser sur les frais. Il peut être utile d’expérimenter pour déterminer si ces frais extrêmement faibles peuvent être utilisés pour des consolidations et d’autres transferts intraportefeuille non sensibles au temps.

Nouvelles

• ● Discussion et revue de BIP174 en cours : ce BIP crée un format standardisé permettant aux portefeuilles de partager de manière fiable des informations liées à des transactions non signées et partiellement signées. Il est prévu qu’il soit implémenté dans Bitcoin Core et puisse également être implémenté dans d’autres portefeuilles, permettant aux portefeuilles logiciels, portefeuilles matériels, et portefeuilles hors ligne (cold) d’interagir facilement entre eux pour les transactions à signature unique comme multi-signatures. Ce BIP a le potentiel de devenir une norme de l’industrie et tous les principaux fournisseurs de portefeuilles sont donc encouragés à étudier la spécification.

  La proposition d’implémentation de BIP174 avait auparavant été ajoutée à la file de revue haute priorité de Bitcoin Core et a suscité d’importantes discussions cette semaine, avec au moins un bug découvert et un développeur du protocole suggérant que certaines parties de la proposition peuvent être séparées.

• ● Filtres de clients légers BIP157/BIP158 : ces BIP permettent aux nœuds de créer un index compact des données de transaction pour chaque bloc de la chaîne puis d’en distribuer des copies aux clients légers qui les demandent. Le client peut alors déterminer en privé si le bloc peut ou non contenir l’une de ses transactions.

  Les données exactes qui devraient être indexées ont été largement discutées sur la liste de diffusion cette semaine. Cela n’affecte probablement pas directement la plupart des grands récepteurs-dépensiers et services d’API, mais les fournisseurs prévoyant de publier des portefeuilles utilisant le protocole réseau pair à pair peuvent vouloir examiner les BIP.

  La PR Bitcoin Core #13243, fusionnée cette semaine, fait partie d’un effort visant à apporter cette fonctionnalité à Bitcoin Core.

• ● BIP proposé pour la sérialisation des clés privées et des portefeuilles HD : actuellement, les clés privées sont généralement transmises en utilisant le même encodage que les adresses Bitcoin legacy, et les clés étendues et graines de portefeuilles HD sont transmises en utilisant soit le même format, soit l’hexadécimal, soit une phrase mnémonique. Cette nouvelle proposition permettrait d’utiliser le format bech32 utilisé pour les adresses segwit natives.

  La discussion s’est concentrée sur la question de savoir s’il fallait ou non utiliser exactement le standard bech32 ou une modification de celui-ci qui serait plus résistante aux erreurs de transcription et de perte de données. Les services qui prévoient d’accepter ou de distribuer du matériel de clés secrètes peuvent souhaiter contribuer à la revue de la spécification.

• ● Protocole de minage BetterHash : un remplacement proposé pour le protocole de minage Stratum actuellement utilisé presque universellement par les pools de minage pour distribuer du travail aux mineurs individuels. La proposition affirme fournir une meilleure sécurité pour l’opérateur du pool et permet aux mineurs individuels de sélectionner les transactions qu’ils incluent dans leurs blocs, augmentant la résistance de Bitcoin à la censure et rendant aussi possiblement les mineurs utilisant le protocole plus efficaces. Le protocole est porté par le développeur et opérateur du réseau FIBRE utilisé par presque tous les mineurs.

  Le protocole est en développement semi-privé depuis un certain temps et n’est distribué pour commentaire public que maintenant. Les organisations prévoyant de vendre ou d’exploiter du matériel de minage sont encouragées à examiner le protocole, de même que tous les groupes ou individus souhaitant des changements aux règles de consensus de Bitcoin afin que le protocole puisse potentiellement être rendu compatible à l’avenir avec ces changements. Il n’y a pas encore eu beaucoup de discussion sur la liste à propos de la proposition.

Ce jour-là dans l’historique des commits Bitcoin…

• ● 2017 : Andrew Chow a rédigé le commit ec6902d ouvrant la voie à la suppression des dernières parties de la fonctionnalité déroutante de « safe mode » ajoutée à Bitcoin 0.3.x après l’incident de dépassement de valeur.

• ● 2016 : La PR de Luke Dashjr #7935 a été fusionnée, ajoutant le support des versionbits BIP9 à l’appel RPC GetBlockTemplate, permettant aux mineurs de signaler leur prise en charge de futurs soft forks—comme le soft fork qui a activé BIP141 segregated witness.

• ● 2015 : Gavin Andresen a rédigé le commit 65b94545 afin d’affiner les critères qu’un nœud utilise pour détecter qu’il pourrait ne plus recevoir de blocs de la meilleure chaîne de blocs.

• ● 2014 : Cozz Lovan a rédigé le commit 95a93836 supprimant une partie legacy de l’interface graphique qui supposait que tout frais de transaction inférieur à 0,01 BTC constituait de faibles frais de transaction.

• ● 2013 : Wladimir van der Laan a rédigé le commit 3e9c8ba corrigeant un bug lié au répertoire de données.

• ● 2012 : Luke Dashjr a rédigé plusieurs commits (par ex. 9655d73) liés à l’activation du support IPv6.

• ● 2011, 2010, 2009 : aucun commit daté du 8 juin.