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 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 et Braiins. 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 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, jour 2, jour 3, jour 4) et les vidéos des présentations devraient être publiées prochainement. Les vidéos du hackday sont déjà disponibles : jour 1, jour 2.

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 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 ? 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 ? 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 ? 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 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, LND, C-lightning, et libsecp256k1.

• ● 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é 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.

• ● 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 du minage. Une méthode de remplacement, 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. En plus de vous permettre de passer un argument supplémentaire à la 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, #7, #9, #12, et #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 et #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.