Le bulletin de cette semaine résume une idée pour empêcher l’épinglage des transactions coinjoin et expose une proposition pour utiliser de manière spéculative les changements de consensus espérés. Vous y trouverez également une nouvelle contribution à notre série hebdomadaire limitée sur la politique de mempool, ainsi que 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

  • ● Prévenir l’épinglage des coinjoin avec le relai de transaction v3 : Greg Sanders a posté sur la liste de diffusion Bitcoin-Dev une description de la manière dont les règles de relai de transaction v3 proposées pourraient permettre de créer une transaction multipartite de type coinjoin qui ne serait pas vulnérable à l’épinglage de transaction. Le problème spécifique de l’épinglage est que l’un des participants à un coinjoin peut utiliser sa contribution à la transaction pour créer une transaction conflictuelle qui empêche la transaction coinjoin de se confirmer.

    Sanders propose que les transactions de type coinjoin puissent éviter ce problème en demandant à chaque participant de dépenser initialement ses bitcoins dans un script qui ne peut être dépensé que par une signature de tous les participants au coinjoin ou par le seul participant après l’expiration d’un timelock. Par ailleurs, dans le cas d’un coinjoin coordonné, le coordinateur et le participant doivent signer ensemble (ou le participant seul après l’expiration du timelock).

    Jusqu’à l’expiration du délai, le participant doit maintenant obtenir des autres parties ou du coordinateur qu’ils cosignent toute transaction conflictuelle, ce qu’ils ne feront probablement pas, à moins que la signature ne soit dans l’intérêt de tous les participants (par exemple, un fee bump).

  • ● Spéculer en utilisant les changements de consensus espérés : Robin Linus a exposé sur la liste de diffusion Bitcoin-Dev une idée pour dépenser de l’argent dans un fragment de script qui ne peut pas être exécuté pendant une longue période (par exemple 20 ans). Si ce fragment de script est interprété selon les règles actuelles de consensus, il permettra aux mineurs dans 20 ans de réclamer tous les fonds qui lui ont été versés. Toutefois, le fragment est conçu de manière à ce qu’une mise à jour des règles de consensus lui donne une signification différente. Linus donne l’exemple d’un opcode OP_ZKP_VERIFY qui, s’il est ajouté à Bitcoin, permettra à toute personne fournissant une preuve de zéro connaissance (ZKP) pour un programme avec un hachage particulier de réclamer les fonds.

    Cela pourrait permettre aux gens de dépenser aujourd’hui des BTC dans l’un de ces scripts et d’utiliser la preuve de cette dépense pour recevoir un montant équivalent de BTC sur une sidechain ou une chaîne alternative, appelée one-way peg. Les BTC sur l’autre chaîne peuvent être dépensés de manière répétée pendant 20 ans, jusqu’à ce que le timelock du script expire. Ensuite, le propriétaire actuel des BTC sur l’autre chaîne pourrait générer une preuve ZKP qu’il les possède et utiliser cette preuve pour retirer le dépôt bloqué sur le réseau principal de Bitcoin, créant ainsi un two-way peg. Avec une bonne conception du programme de vérification, le retrait serait simple et flexible, ce qui permettrait des retraits fongibles.

    Les auteurs notent que toute personne qui bénéficierait de cette construction (par exemple, qui reçoit des BTC sur une autre chaîne) fait en fait le pari que les règles de consensus de Bitcoin seront modifiées (par exemple, OP_ZKP_VERIFY sera ajouté). Cela les incite à plaider en faveur du changement, mais en incitant fortement certains utilisateurs à changer le système, d’autres utilisateurs pourraient avoir l’impression d’être contraints. L’idée n’a fait l’objet d’aucune discussion sur la liste de diffusion au moment de la rédaction de ce document.

En attente de confirmation #7 : Ressources du réseau

Une série hebdomadaire limitée sur le relais de transaction, l’inclusion dans le mempool et la sélection des transactions minières—y compris pourquoi Bitcoin Core a une politique plus restrictive que celle permise par le consensus et comment les portefeuilles peuvent utiliser cette politique de la manière la plus efficace.

Un article précédent traitait de la protection des ressources des nœuds, qui peut être unique à chaque nœud et donc parfois configurable. Nous avons également expliqué pourquoi il est préférable de converger vers une seule politique, mais qu’est-ce qui doit faire partie de cette politique ? Ce billet aborde le concept de ressources à l’échelle du réseau, essentielles pour des aspects tels que l’évolutivité, la mise à niveau et l’accessibilité du démarrage et de la maintenance d’un nœud complet.

Comme nous l’avons vu dans les articles précédents, de nombreux objectifs idéologiques du réseau Bitcoin sont incarnés par sa structure distribuée. La nature pair-à-pair de Bitcoin permet aux règles du réseau d’émerger d’un consensus approximatif des choix des opérateurs de nœuds individuels et limite les tentatives d’acquisition d’une influence indue sur le réseau. Ces règles sont ensuite appliquées par chaque nœud qui valide individuellement chaque transaction. Une population de nœuds diversifiée et saine exige que le coût d’exploitation d’un nœud soit maintenu à un niveau bas. Il est difficile de faire évoluer un projet avec une audience mondiale, mais le faire sans sacrifier la décentralisation revient à se battre avec une main attachée dans le dos. Le projet Bitcoin tente de trouver cet équilibre en protégeant farouchement les ressources partagées du réseau : le stock d’UTXO, l’empreinte des données de la blockchain et l’effort de calcul nécessaire pour les traiter, ainsi que les mises à jour permettant de faire évoluer le protocole Bitcoin.

Il n’est pas nécessaire de revenir sur la guerre des tailles de blocs pour comprendre qu’une limite à la croissance de la blockchain est nécessaire pour que l’exploitation de son propre nœud reste abordable. Cependant, la croissance de la blockchain est également dissuadée au niveau politique par le minRelayTxFee de 1 sat/vbyte, assurant un coût minimum pour exprimer une partie de la “ demande illimitée de stockage perpétuel hautement répliqué “.

À l’origine, l’état du réseau était déterminé en conservant toutes les transactions dont les résultats n’avaient pas encore été dépensés. Cette partie beaucoup plus importante de la blockchain a été réduite de manière significative avec l’introduction du jeu d’UTXO comme moyen de suivre les fonds. Depuis lors, le jeu d’UTXO est une structure de données centrale. En particulier pendant les IBD, mais aussi de manière générale, les consultations d’UTXO représentent une part importante de tous les accès à la mémoire d’un nœud. Bitcoin Core utilise déjà une structure de données optimisée manuellement pour le cache UTXO, mais la taille du jeu d’UTXO détermine la quantité qu’il ne peut pas contenir dans le cache d’un nœud. Un ensemble d’UTXO plus important se traduit par un plus grand nombre d’échec du cache, ce qui ralentit la vitesse de validation des blocs, de l’IBD et de la transaction. La limite des poussières (dust limit) est un exemple de politique qui restreint la création d’UTXO, en particulier les UTXO qui pourraient ne jamais être dépensés parce que leur montant n’est pas à la hauteur du coût de leur dépense. Malgré cela, des “tempêtes de poussière” avec des milliers de transactions se sont produites pas plus tard qu’en 2020.

Lorsqu’il est devenu populaire d’utiliser des sorties multisig brutes pour publier des données sur la blockchain, la définition des transactions standards a été modifiée pour permettre une sortie OP_RETURN unique en tant qu’alternative. Les gens ont réalisé qu’il serait impossible d’empêcher les utilisateurs de publier des données sur la blockchain, mais qu’au moins ces données n’auraient pas besoin de vivre dans le jeu d’UTXO pour toujours lorsqu’elles sont publiées dans des sorties qui ne peuvent jamais être dépensées. Bitcoin Core 0.13.0 a introduit une option de démarrage -permitbaremultisig que les utilisateurs peuvent activer pour rejeter les transactions non confirmées avec des sorties multisig brutes.

Bien que les règles de consensus permettent aux scripts de sortie d’être libres, seuls quelques modèles bien compris sont relayés par les nœuds de Bitcoin Core. Il est ainsi plus facile de comprendre les nombreuses préoccupations du réseau, notamment les coûts de validation et les mécanismes de mise à jour du protocole. Par exemple, un script d’entrée qui contient des op-codes, une entrée P2SH avec plus de 15 signatures, ou une entrée P2WSH dont la pile de témoins contient plus de 100 éléments chacun, rendrait une transaction non standard. (Consultez cette vue d’ensemble des politiques pour plus d’exemples de politiques et leurs motivations).

Finalement, le protocole Bitcoin est un projet logiciel vivant qui devra continuer à évoluer pour répondre aux défis futurs et aux besoins des utilisateurs. À cette fin, il existe un certain nombre de mécanismes de mise à jour qui ont délibérément laissé le consensus valide mais inutilisé, tels que l’annexe, les versions des leaf taproots, les versions des témoins, OP_SUCCESS et un certain nombre d’opcodes no-op. Cependant, tout comme les attaques sont entravées par l’absence de points centraux de défaillance, les mises à jour logicielles à l’échelle du réseau impliquent un effort coordonné entre des dizaines de milliers d’opérateurs de nœuds indépendants. Les nœuds ne relaieront pas les transactions qui utilisent les hooks de mise à niveau réservés tant que leur signification n’aura pas été définie. Cette mesure vise à dissuader les applications de créer indépendamment des normes contradictoires, ce qui rendrait impossible l’adoption de la norme d’une application dans le consensus sans invalider celle d’une autre application. En outre, lorsqu’un changement de consensus se produit, les nœuds qui ne sont pas mis à niveau immédiatement—et qui ne connaissent donc pas les nouvelles règles de consensus—ne peuvent pas être “trompés” en acceptant une transaction désormais invalide dans leur pool de mémoires. Ce découragement proactif aide les nœuds à être compatibles avec l’avenir et permet au réseau de mettre à jour les règles de consensus en toute sécurité sans nécessiter une mise à jour logicielle entièrement synchronisée.

Nous pouvons voir que l’utilisation d’une politique pour protéger les ressources partagées du réseau aide à protéger les caractéristiques du réseau, et maintient ouvertes les voies pour le développement de protocoles futurs. Pendant ce temps, nous voyons comment la friction de la croissance du réseau contre une blockchain strictement limitée a conduit à l’adoption de meilleures pratiques, d’une bonne conception technique et de l’innovation : le billet de la semaine prochaine explorera la politique de mempool comme une interface pour les protocoles de deuxième couche et les systèmes de contrats intelligents.

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.

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.

  • ● BTCPay Server 1.10.3 est la dernière version de ce logiciel de traitement de paiement auto-hébergé. Consultez leur billet de blog pour une visite des principales fonctionnalités de la branche 1.10.

Changements notables dans le code et la documentation

Changements notables cette semaine dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, et Bitcoin Inquisition.

  • ● Core Lightning #6303 ajoute une nouvelle RPC setconfig qui permet de changer certaines options de configuration sans redémarrer le démon.

  • ● Eclair #2701 commence l’enregistrement à la fois au moment où un HTLC offert est reçu et au moment où il est réglé. Cela permet de savoir combien de temps le HTLC a été en attente du point de vue du nœud. Si de nombreux HTLC, ou quelques HTLC de grande valeur, sont en attente pendant de longues périodes, cela peut indiquer qu’une attaque par brouillage de canal est en cours. Le suivi de la durée des HTLC permet de détecter de telles attaques et peut contribuer à les atténuer.

  • ● Eclair #2696 modifie la façon dont Eclair permet aux utilisateurs de configurer les taux de frais à utiliser. Auparavant, les utilisateurs pouvaient spécifier la vitesse à utiliser avec un block target, par exemple, un réglage de “6” signifiait qu’Eclair essaierait de faire confirmer une transaction dans un délai de six blocs. Désormais, Eclair accepte les termes “lent”, “moyen” et “rapide”, qu’il traduit en taux de frais spécifiques à l’aide de constantes ou de cibles de blocs.

  • ● LND #7710 ajoute la possibilité pour les plugins (ou le démon lui-même) de récupérer les données reçues plus tôt dans un HTLC. Ceci est nécessaire pour le route aveugle et peut être utilisé par diverses contre-mesures de brouillage de canal, parmi d’autres idées pour de futures fonctionnalités.

  • ● LDK #2368 permet d’accepter de nouveaux canaux créés par un pair qui utilise des sorties d’ancrage mais exige que le programme de contrôle choisisse délibérément d’accepter chaque nouveau canal. En effet, pour régler correctement un canal d’ancrage, l’utilisateur doit avoir accès à un ou plusieurs UTXO de valeur suffisante. LDK, en tant que bibliothèque ignorant quels UTXOs non-LN le portefeuille de l’utilisateur contrôle, utilise cette requête pour donner au programme de contrôle une chance de vérifier qu’il a les UTXOs nécessaires.

  • ● LDK #2367 rend les canaux d’ancrage accessibles aux consommateurs réguliers de l’API.

  • ● LDK #2319 permet à un pair de créer un HTLC qui s’engage à payer moins que le montant que le contributeur original a dit devoir être payé, ce qui permet au pair de garder la différence pour lui-même en tant que frais supplémentaires. Ceci est utile pour la création de JIT channels où un pair reçoit un HTLC pour un destinataire qui n’a pas encore de canal. Le pair crée une transaction onchain qui finance le canal et s’engage dans le HTLC au sein de ce canal—mais il encourt des frais de transaction supplémentaires en créant cette transaction onchain. En prenant des frais supplémentaires, il est compensé pour ses coûts si le destinataire accepte le nouveau canal et règle le HTLC à temps.

  • ● LDK #2120 ajoute la prise en charge de la recherche d’un itinéraire vers un destinataire qui utilise des chemins aveugles.

  • ● LDK #2089 ajoute un gestionnaire d’événement qui permet aux portefeuilles de déclencher facilement les HTLC qui doivent être réglés onchain.

  • ● LDK #2077 remanie une grande partie du code pour faciliter l’ajout ultérieur de la prise en charge des canaux à double financement.

  • ● Libsecp256k1 #1129 implémente la technique ElligatorSwift pour introduire un encodage de clé publique de 64 octets qui est informatiquement indiscernable des données aléatoires. Le module ellswift fournit des fonctions pour encoder et décoder les clés publiques dans le nouveau format ainsi que des fonctions de commodité pour générer de nouvelles clés uniformément aléatoires et effectuer un échange de clés Diffie-Hellman à courbe elliptique (ECDH) sur les clés encodées ellswift. L’ECDH basé sur ellswift doit être utilisé pour établir des connexions pour le protocole transport P2P chiffré version 2 (BIP324).