Le bulletin de cette semaine décrit une proposition visant à permettre le remplacement des transactions v3 en utilisant les règles RBF pour faciliter la transition vers le mempool en cluster et résume un argument contre OP_CHECKTEMPLATEVERIFY basé sur le fait qu’il nécessite généralement des frais exogènes. Sont également incluses nos sections régulières résumant les principales questions et réponses de Bitcoin Stack Exchange, annonçant de nouvelles versions et des versions candidates, et décrivant les principaux changements apportés aux projets d’infrastructure Bitcoin.

Nouvelles

  • ● Remplacement par frais de parenté : Gloria Zhao a posté sur Delving Bitcoin pour permettre à une transaction de remplacer une transaction connexe dans le mempool même s’il n’y a pas de conflit entre les deux transactions. Deux transactions sont considérées comme conflictuelles lorsqu’elles ne peuvent pas toutes deux exister dans la même chaîne de blocs valide, généralement parce qu’elles essaient toutes deux de dépenser la même UTXO, en violation de la règle contre le double dépense. Les règles pour RBF comparent une transaction dans le mempool à une nouvelle transaction reçue qui entre en conflit avec elle. Zhao suggère une façon idéalisée de penser à une politique de conflits : si un nœud de relais a deux transactions mais ne peut en accepter qu’une seule, il ne devrait pas choisir celle qui arrive en premier—mais celle qui convient le mieux aux objectifs de l’opérateur du nœud (comme maximiser les revenus des mineurs sans permettre de relais effectivement gratuits). Les règles RBF tentent de le faire pour les conflits ; Zhao, dans son article, étend l’idée aux transactions connexes plutôt qu’aux seuls conflits.

    Bitcoin Core impose des limites politiques sur le nombre et la taille des transactions connexes autorisées simultanément dans le mempool. Cela atténue plusieurs attaques DoS, mais signifie qu’il peut rejeter la transaction B parce qu’il a précédemment reçu la transaction connexe A, qui a atteint les limites. Cela viole le principe de Zhao : au lieu de cela, Bitcoin Core devrait accepter celle de A ou B qui est réellement la meilleure pour ses objectifs.

    Les règles proposées pour la transmission des transactions v3 n’autorisent qu’un parent v3 non confirmé à avoir une seule transaction enfant dans le mempool. Comme aucune des transactions ne peut avoir d’ancêtres ou de dépendants dans le mempool, il est facile d’appliquer les règles RBF existantes aux remplacements d’une transaction enfant v3 et Zhao l’a implémenté. Si, comme décrit dans le bulletin de la semaine dernière, les transactions de commitment LN existantes utilisant les sorties d’ancrage sont automatiquement inscrites dans la politique v3, cela garantirait que chaque partie peut toujours augmenter les frais de la transaction de commitment :

    • Alice peut envoyer la transaction de commitment avec une transaction enfant pour payer les frais.

    • Alice peut ensuite RBF sa transaction enfant existante pour augmenter les frais.

    • Bob peut utiliser le remplacement par parenté pour expulser la transaction enfant d’Alice en envoyant sa propre transaction enfant qui paie des frais plus élevés.

    • Alice peut ensuite utiliser le remplacement par parenté sur la transaction enfant de Bob en envoyant sa propre transaction enfant avec des frais encore plus élevés (en supprimant la transaction enfant de Bob).

    L’ajout de cette politique et son application automatique aux ancres LN actuelles permettra de supprimer la règle de dérogation CPFP, ce qui est nécessaire pour mettre en œuvre le cluster mempool, ce qui devrait permettre de rendre les remplacements de toutes sortes plus incitatifs à l’avenir.

    Au moment de la rédaction de cet article, il n’y avait aucune objection à cette idée sur le forum. Une question notable concernait la nécessité des ancres éphémères, mais l’auteur de cette proposition (Gregory Sanders) a répondu : “Je n’ai pas l’intention d’abandonner le travail sur les ancres éphémères. Les sorties à zéro satoshi ont plusieurs cas d’utilisation importants en dehors de LN.”

  • ● Opposition à CTV basée sur le besoin courant de frais exogènes : Peter Todd a publié sur la liste de diffusion Bitcoin-Dev une adaptation de son argument contre les frais exogènes (voir le Bulletin #284) appliqué à la proposition OP_CHECKTEMPLATEVERIFY. Il note que, “dans de nombreux (si ce n’est tous) cas d’utilisationde CTV destinés à permettre à plusieurs parties de partager une seule UTXO, il est difficile, voire impossible, de permettre suffisamment de variantes de CTV pour couvrir tous les taux de frais possibles. On s’attend à ce que CTV soit généralement utilisé avec des sorties d’ancrage pour payer les frais […] ou éventuellement, via un soft-fork de parrainage de transaction. […] Cette exigence pour que tous les utilisateurs aient une UTXO pour payer les frais annule l’efficacité des schémas de partage d’UTXO utilisant CTV […] la seule alternative réaliste est d’utiliser un tiers pour payer l’UTXO, par exemple via un paiement LN, mais à ce stade, il serait plus efficace de payer des frais miniers hors bande. Cela est bien sûr très indésirable d’un point de vue de la centralisation minière.” (Liens ajoutés par Optech.) Il recommande d’abandonner CTV et de travailler plutôt sur des schémas de convenants compatibles avec RBF.

    John Law a répondu que les délais dépendant des frais (voir le Bulletin #283) pourraient rendre l’utilisation de CTV sûre avec des frais endogènes dans les cas où des versions particulières d’une transaction devaient être confirmées avant une date limite, bien que les délais dépendant des frais puissent retarder certains règlements de contrat pendant une durée indéterminée.

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 lorsque nous avons quelques moments libres pour aider les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en évidence certaines des questions et réponses les plus votées publié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.

  • ● HWI 2.4.0 est une version de la prochaine version de ce package fournissant une interface commune à plusieurs dispositifs de signature matérielle différents. La nouvelle version ajoute la prise en charge de Trezor Safe 3 et contient plusieurs améliorations mineures.

Modifications notables du code et de la documentation

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

  • ● Bitcoin Core #29291 ajoute un test qui échouera si une transaction exécutant un opcode OP_CHECKSEQUENCEVERIFY semble avoir un numéro de version négatif. Ce test, s’il avait été exécuté par des implémentations alternatives de consensus, aurait détecté le bug d’échec du consensus mentionné dans la bulletin de la semaine dernière.

  • ● Eclair #2811, #2813 et #2814 ajoutent la possibilité pour un paiement de trampoline d’utiliser un chemin aveugle pour le destinataire final. Le routage du trampoline lui-même continue d’utiliser des identifiants de nœud chiffrés par oignon réguliers, c’est-à-dire que chaque nœud trampoline apprend l’identifiant du prochain nœud trampoline. Cependant, si un chemin aveugle est utilisé, le dernier nœud trampoline n’apprendra désormais que l’identifiant du nœud d’introduction dans le chemin aveugle; il n’apprendra pas l’identifiant du destinataire final.

    Auparavant, la confidentialité du trampoline fort dépendait de l’utilisation de plusieurs expéditeurs de trampoline de sorte que aucun des expéditeurs ne pouvait être sûr d’être le dernier expéditeur. L’inconvénient de cette approche est qu’elle utilisait des chemins plus longs qui augmentaient la probabilité d’échec de l’acheminement et nécessitaient le paiement de frais d’acheminement supplémentaires pour réussir. Maintenant, le fait de faire transiter les paiements par un seul nœud trampoline peut empêcher ce nœud d’apprendre le destinataire final.

  • ● LND #8167 permet à un nœud LND de fermer mutuellement un canal qui a encore un ou plusieurs paiements en attente (HTLC). La spécification BOLT2 indique que la procédure appropriée consiste pour une partie à envoyer un message shutdown, après quoi aucun nouveau HTLC ne sera accepté. Une fois que tous les HTLC en attente sont résolus off-chain, les deux parties négocient et signent une transaction de fermeture mutuelle. Auparavant, lorsque LND recevait un message shutdown, il forçait la fermeture du canal, ce qui nécessitait des transactions et des frais supplémentaires pour régler.

  • ● LND #7733 met à jour la prise en charge des tour de guets pour permettre la sauvegarde et l’application de la fermeture correcte des canaux simples taproot qui sont maintenant pris en charge de manière expérimentale par LND.

  • ● LND #8275 commence à exiger que les pairs prennent en charge certaines fonctionnalités universellement déployées telles que spécifiées dans BOLTs #1092 (voir le Bulletin #259).

  • ● Rust Bitcoin #2366 déprécie la méthode .txid() sur les objets Transaction et commence à fournir une méthode de remplacement nommée .compute_txid(). Chaque fois que la méthode .txid() est appelée, l’identifiant de transaction est calculé, ce qui consomme suffisamment de CPU pour être préoccupant pour toute personne exécutant la fonction sur de grandes transactions ou de nombreuses transactions plus petites. On espère que le nouveau nom de la méthode aidera les programmeurs en aval à réaliser ses coûts potentiels. Les méthodes .wtxid() et .ntxid() (respectivement basées sur BIP141 et BIP140) sont également renommées en .compute_wtxid() et .compute_ntxid().

  • ● HWI #716 ajoute la prise en charge du dispositif de signature matérielle Trezor Safe 3.

  • ● BDK #1172 ajoute une API bloc par bloc pour le portefeuille. Un utilisateur ayant accès à une séquence de blocs peut itérer sur ces blocs pour mettre à jour le portefeuille en fonction des transactions dans ces blocs. Cela peut être utilisé pour synchroniser un portefeuille avec la blockchain et mettre à jour les soldes et les transactions. Cela permet une intégration plus étroite entre le portefeuille et la blockchain, offrant une meilleure expérience utilisateur. Cela peut simplement être utilisés pour itérer sur chaque bloc d’une chaîne. Alternativement, le logiciel peut utiliser une sorte de méthode de filtrage (par exemple, filtres de bloc compacts) pour trouver uniquement les blocs susceptibles de contenir des transactions affectant le portefeuille, et itérer sur ce sous-ensemble de blocs.

  • ● BINANAs #3 ajoute BIN24-5 avec une liste de référentiels de spécifications liés à Bitcoin, tels que BIPs, BOLTs, BLIPs, SLIPs, LNPBPs et spécifications DLC. Certains référentiels de spécifications pour d’autres projets connexes sont également répertoriés.