Le bulletin de cette semaine comprend le tableau de bord habituel et les actions à entreprendre, un article de fond du développeur Anthony Towns sur la consolidation de quatre millions d’UTXO chez Xapo, des nouvelles à propos de possibles mises à niveau du système de script de Bitcoin, des liens vers quelques questions et réponses très plébiscitées sur Bitcoin Stack Exchange, ainsi que quelques commits notables dans les branches de développement des projets Bitcoin Core, Lightning Network Daemon (LND) et C-lightning.

Mesures à prendre

• ● Bitcoin Core 0.16.2 publié : une version mineure qui apporte des corrections de bugs et de petites améliorations. Si vous utilisez les RPC abandontransaction ou verifytxoutproof, vous devriez tout particulièrement envisager une mise à niveau. Sinon, nous vous recommandons d’examiner les notes de version pour les autres changements qui pourraient affecter votre activité et de mettre à niveau lorsque cela vous convient.

Éléments du tableau de bord

• ● Frais toujours bas : le taux de hachage a augmenté la difficulté de plus de 14 % durant la période de réajustement de 2 016 blocs qui s’est terminée dimanche, donnant un temps moyen entre les blocs de 8 minutes et 41 secondes. Cela a aidé à absorber la charge transactionnelle accrue due à la spéculation sur les prix de la semaine passée. Immédiatement après un réajustement de difficulté, le temps moyen entre les blocs est rétabli à 10 minutes.

  Alors que nous passons du calme habituel des transactions du week-end à la nouvelle semaine, il existe une possibilité d’augmentation rapide des estimations de frais de transaction. Nous recommandons de faire preuve de prudence lors de l’envoi de grosses transactions à faibles frais telles que les consolidations jusqu’à se rapprocher du week-end, quand le volume de transactions commence à nouveau à diminuer.

Rapport de terrain : Consolidation de 4 millions d’UTXO chez Xapo

par Anthony Towns, développeur sur Bitcoin Core chez Xapo

Lire l’article sur la consolidation de quatre millions d’UTXO chez Xapo (en anglais).

Nouvelles

• ● “Improvements in the Bitcoin Scripting Language” par Pieter Wuille : une présentation la semaine dernière donnant une vue d’ensemble de haut niveau de plusieurs améliorations possibles à court terme pour Bitcoin. Nous recommandons fortement de regarder la vidéo, de consulter les diapositives, ou de lire la transcription (avec références) par Bryan Bishop—mais si vous êtes trop occupé, voici la conclusion de Wuille : “mon objectif initial ici est les signatures Schnorr et taproot. La raison de cette focalisation est que la capacité à faire apparaître n’importe quelle entrée et sortie dans le cas coopératif comme identiques est un gain énorme pour le fonctionnement de l’exécution des scripts.

  “Schnorr est nécessaire pour cela car sans lui nous ne pouvons pas encoder plusieurs parties dans une seule clé. Le fait d’avoir plusieurs branches là-dedans est un changement relativement simple.

  “Si vous regardez les modifications du consensus nécessaires pour ces choses, c’est en réalité remarquablement faible, quelques dizaines de lignes de code. On dirait que la majeure partie de la complexité réside dans l’explication de l’utilité de ces choses et de la manière de les utiliser, et non pas tant dans leur impact sur les règles de consensus.

  “Des choses comme l’agrégation, je pense, sont quelque chose qui pourra être fait après que nous aurons exploré diverses options pour des améliorations structurelles du langage de script, une fois qu’il sera clair comment la structuration devrait être faite, parce que nous apprendrons probablement des déploiements comment ces choses sont utilisées en pratique. C’est ce sur quoi je travaille avec un certain nombre de collaborateurs et nous proposerons espérons-le quelque chose bientôt, et c’est la fin de ma présentation.”

Questions et réponses sélectionnées de Bitcoin Stack Exchange

Bitcoin Stack Exchange 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 à répondre aux questions d’autres personnes. Dans cette nouvelle rubrique mensuelle, nous mettons en lumière certaines des questions et réponses les mieux votées publiées au cours du mois écoulé.

• ● Schnorr versus ECDSA : dans cette réponse, le développeur du protocole Bitcoin Pieter Wuille explique certains des principaux avantages du schéma de signature Schnorr par rapport au schéma actuel de signature ECDSA de Bitcoin.

• ● Pourquoi la dérivation des clés HD cesse-t-elle de fonctionner après un certain indice dans les portefeuilles BIP44 ? : un développeur testant son portefeuille constate qu’un paiement envoyé à des indices de clé peu élevés fonctionne comme prévu, mais que les paiements envoyés à des indices plus élevés n’apparaissent jamais dans ses portefeuilles. Une réponse de Viktor T. révèle pourquoi.

• ● Quelle est la taille maximale d’une signature Bitcoin encodée en DER ? : dans cette réponse, Pieter Wuille fournit les calculs pour déterminer la taille d’une signature Bitcoin. Comme mentionné dans le Bulletin #3, la taille maximale avec un portefeuille ordinaire est de 72 octets—mais Wuille explique comment vous pouvez créer une transaction non standard avec une signature de 73 octets et pourquoi vous pourriez penser avoir vu une signature de 74 voire 75 octets.

• ● Si presque tous les opcodes sont utilisables dans P2SH, pourquoi ne le sont-ils pas dans les scriptPubKeys ? : dans cette réponse, le rédacteur technique Bitcoin David A. Harding explique pourquoi les premières versions de Bitcoin restreignaient les types de transactions pouvant être envoyées aux “transactions standards” et pourquoi la plupart de ces restrictions sont toujours en place même si presque tous les opcodes sont désormais disponibles pour un usage standard via P2SH et segwit P2WSH.

Changements notables dans le code et la documentation

Un bref aperçu des fusions et commits récents réalisés dans divers projets Bitcoin open source.

• ● Bitcoin Core #12257 : si vous démarrez Bitcoin Core avec l’option -avoidpartialspends, le portefeuille dépensera par défaut toutes les sorties reçues à la même adresse dès que l’une d’entre elles devrait être dépensée. Cela empêche que deux sorties vers la même adresse soient dépensées dans des transactions distinctes, ce qui est une manière courante par laquelle la réutilisation d’adresse réduit la confidentialité. L’inconvénient est que cela peut rendre les transactions plus grandes que leur taille minimale nécessaire. Les entreprises Bitcoin utilisant le portefeuille intégré de Bitcoin Core et n’ayant pas besoin de cette confidentialité supplémentaire peuvent tout de même vouloir activer cette option lorsque les frais sont faibles afin de consolider automatiquement les entrées liées.

• ● LND #1617 : met à jour les estimations de la taille des transactions on-chain afin d’empêcher que des transactions paient accidentellement des frais trop faibles et restent bloquées. Ce commit peut être intéressant pour quiconque s’interroge sur la taille des transactions (et des parties de transactions) produites dans le protocole actuel.

• ● LND #1531 : le daemon ne recherche plus les dépenses dans la mempool—il attend d’abord qu’elles fassent partie confirmée d’un bloc. Cela permet au même code de fonctionner sur des nœuds complets comme Bitcoin Core et btcd ainsi que sur des clients légers basés sur BIP157 qui n’ont pas accès aux transactions non confirmées. Cela fait partie de l’effort continu visant à aider les personnes sans nœud complet à utiliser LN.

• ● Dans plusieurs commits, les développeurs de C-lightning ont pour l’essentiel achevé la transition consistant à gérer les fonctions liées aux pairs dans gossipd vers leur gestion dans channeld ou connectd selon le cas.

• C-lightning a amélioré sa gestion des secrets afin que les secrets et signatures soient toujours générés et stockés par un daemon séparé des parties du système directement connectées au réseau.