Bulletin hebdomadaire Bitcoin Optech n°281

by
Ailleurs
My articles My books
Follow on:

Bulletin d’information hebdomadaire Bitcoin Optech du 13 décembre 2023 traduit par @copinmalin.

Le bulletin de cette semaine résume une discussion sur le griefing des annonces de liquidité et inclut nos sections régulières concernant les questions et réponses populaires sur le Bitcoin Stack Exchange, les nouvelles versions et les versions candidates, et les changements apportés aux principaux logiciels de l’infrastructure Bitcoin.

Nouvelles

Discussion sur le problème des annonces de liquidité : Bastien Teinturier a évoqué sur la liste de diffusion Lightning-Dev un problème potentiel avec les timelocks sur les canaux à financement double créés à partir des annonces de liquidité. Cela a également été mentionné précédemment dans le Récapitulatif n°279. Par exemple, Alice annonce qu’elle est prête, moyennant des frais, à engager 10 000 sats de ses fonds dans un canal pendant 28 jours. Le timelock de 28 jours empêche Alice de simplement fermer le canal après avoir reçu le paiement et d’utiliser ses fonds à d’autres fins.

Poursuivant l’exemple, Bob ouvre le canal avec une contribution supplémentaire de 100 000 000 sats (1 BTC) de ses fonds. Il envoie ensuite presque tous ses fonds à travers le canal. Maintenant, le solde d’Alice dans le canal n’est pas de 10 000 sats pour lesquels elle a reçu des frais, mais presque 10 000 fois plus élevé que cette somme. Si Bob est malveillant, il n’autorisera pas ces fonds à se déplacer à nouveau avant l’expiration du timelock de 28 jours auquel Alice s’est engagée.

Une atténuation suggérée par Teinturier et discutée par lui-même et d’autres consistait à n’appliquer le timelock qu’à la contribution de liquidité (par exemple, seulement les 10 000 sats d’Alice). Cela introduit des complexités et des inefficacités, bien que cela puisse résoudre le problème. Une alternative proposée par Teinturier était simplement de supprimer le timelock (ou de le rendre facultatif) et de laisser les acheteurs de liquidité prendre le risque que les fournisseurs puissent fermer les canaux peu de temps après avoir reçu leurs frais de liquidité. Si les canaux ouverts via des annonces de liquidité génèrent généralement des revenus de frais de transfert importants, il y aurait une incitation à les maintenir ouverts.

Modifications apportées aux services et aux logiciels clients

Dans cette rubrique mensuelle, nous mettons en évidence les mises à jour intéressantes des portefeuilles et services Bitcoin.

Lancement d’un pool de minage Stratum v2 : DEMAND est un pool de minage construit à partir de l’implémentation de référence Stratum v2 permettant initialement le minage en solo, avec le minage en pool prévu pour l’avenir.

Annonce de l’outil de simulation du réseau Bitcoin warnet : Le logiciel warnet permet de spécifier des topologies de nœuds, d’exécuter des scénarios scriptés sur ce réseau et de surveiller et analyser les comportements qui en résultent.

Publication d’un client Payjoin pour Bitcoin Core : Le payjoin-cli est un projet en Rust qui ajoute des fonctionnalités d’envoi et de réception de payjoin en ligne de commande pour Bitcoin Core.

Appel aux horodatages d’arrivée des blocs par la communauté : Un contributeur au référentiel Bitcoin Block Arrival Time Dataset a appelé les opérateurs de nœuds à soumettre leurs horodatages d’arrivée de bloc à des fins de recherche. Il existe un référentiel similaire pour collecter des données sur les blocs obsolètes.

Envoy 1.4 publié : La version 1.4 du portefeuille Bitcoin Envoy ajoute notamment la gestion des pièces et l’étiquetage des portefeuilles (BIP329 à venir), ainsi que d’autres fonctionnalités.

Annonce du schéma d’encodage BBQr : Le schéma peut encoder efficacement des fichiers plus volumineux, tels que des PSBT, en une série de QR animés pour une utilisation dans des configurations de portefeuille hors ligne.

Zeus v0.8.0 publié : La version v0.8.0 de Zeus contient un nœud LND intégré, un support supplémentaire pour les canaux zero conf et les canaux taproot simples, entre autres modifications.

Sélection de Q&R du Bitcoin Stack Exchange

Bitcoin Stack Exchange est l’un des premiers endroits où les contributeurs d’Optech cherchent des réponses à leurs questions—ou lorsque nous avons quelques moments libres pour aider les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en avant certaines des questions et réponses les plus appréciées, postées depuis notre dernière mise à jour.

Quelles sont toutes les règles liées à l’augmentation des frais CPFP ? Pieter Wuille souligne que contrairement à la technique d’augmentation des frais RBF qui a une liste de règles de politique associées, la technique d’augmentation des frais CPFP n’a pas de règles de politique supplémentaires.

Comment est calculé le nombre total de transactions de remplacement RBF ? Murch et Pieter Wuille présentent quelques exemples de remplacements RBF dans le contexte de la règle 5 de BIP125 : “Le nombre de transactions d’origine à remplacer et de leurs transactions descendantes qui seront supprimées de la mempool ne doit pas dépasser un total de 100 transactions”. Les lecteurs peuvent également être intéressés par la réunion du PR Review Club sur l’ajout du test de cas de la règle 5 de BIP-125 avec la mempool par défaut.

Quels types de RBF existent et lequel Bitcoin Core prend-il en charge et utilise-t-il par défaut ? Murch fournit une partie de l’historique des remplacements de transactions de Bitcoin Core et, dans une question connexe, un résumé des règles de remplacement RBF et des liens vers la documentation de Bitcoin Core sur les remplacements de mempool et les idées d’un développeur pour améliorer le RBF.

Quel est le problème du bloc 1 983 702 ? Antoine Poinsot donne un aperçu des problèmes qui ont conduit à la restriction des txids en double par BIP30 et à l’obligation d’inclure le numéro de bloc par BIP34 à la hauteur de bloc actuelle dans le champ coinbase. Il souligne ensuite qu’il existe de nombreux blocs dont le contenu du champ coinbase correspond par hasard au préfixe de hauteur obligatoire d’un bloc ultérieur. Le bloc 1 983 702 étant le premier pour lequel il serait pratiquement possible de répéter la transaction coinbase du bloc précédent. Dans une question connexe, Murch et Antoine Poinsot évaluent cette possibilité plus en détail. Voir également le Bulletin #182.

À quoi servent les fonctions de hachage dans Bitcoin ? Pieter Wuille liste plus de trente instances différentes à travers les règles de consensus, le protocole pair-à-pair, les détails de mise en œuvre du portefeuille et du nœud qui utilisent pas moins de 10 fonctions de hachage différentes.

Mises à jour et versions candidates

Nouvelles versions et versions candidates pour les principaux projets d’infrastructure Bitcoin. Veuillez envisager de passer aux nouvelles versions ou d’aider à tester les versions candidates.

LND 0.17.3-beta est une version qui contient plusieurs corrections de bugs, y compris une réduction de la mémoire lorsqu’elle est utilisée avec le backend Bitcoin Core.

Changements notables dans le code et la documentation

Changements notables cette semaine dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Interface de portefeuille matériel (HWI), Rust Bitcoin, Serveur BTCPay, BDK, Propositions d’amélioration de Bitcoin (BIPs), Lightning BOLTs, et Bitcoin Inquisition.

LDK #2685 ajoute la possibilité d’obtenir des données de chaîne de blocs à partir d’un serveur de style Electrum.

Libsecp256k1 #1446 supprime une partie du code d’assemblage x86_64 du projet, en passant à l’utilisation du code en langage C existant qui a toujours été utilisé pour d’autres plates-formes. Le code d’assemblage a été optimisé pour des humains il y a plusieurs années pour améliorer les performances, mais entre-temps, les compilateurs se sont améliorés et les versions récentes de GCC et LLVM (clang) produisent maintenant un code encore plus performant.

BTCPay Server #5389 ajoute la prise en charge de la configuration de portefeuille multisig sécurisé BIP129 (voir le Bulletin #136). Cela permet à permis à BTCPay server d’interagir avec plusieurs portefeuilles logiciels et appareils de signature matériels dans le cadre d’une procédure simple de configuration multisig coordonnée.

BTCPay Server #5490 commence à utiliser par défaut les estimations de frais de mempool.space avec une solution de secours sur les estimations de frais du nœud local Bitcoin Core. Les développeurs commentant la PR ont noté qu’ils estimaient que les estimations de frais de Bitcoin Core ne réagissent pas rapidement aux changements dans le mempool local. Pour une discussion précédente sur les défis liés à l’amélioration de l’exactitude de l’estimation des frais, voir Bitcoin Core #27995.

Joyeuses fêtes !

Ceci est le dernier bulletin hebdomadaire de Bitcoin Optech de l’année. Le mercredi 20 décembre, nous publierons notre sixième bulletin annuel rétrospectif. La publication régulière reprendra le mercredi 3 janvier.