Ce bulletin décrit une proposition visant à supprimer des détails de la spécification LN qui ne sont plus pertinents pour les nœuds récents et inclut l’avant-dernière entrée de notre série hebdomadaire limitée sur la politique de mempool, ainsi que nos sections habituelles résumant une réunion du Bitcoin Core PR Review Club, annonçant de nouvelles versions et versions candidates, et décrivant les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

  • ● Proposition de nettoyage de la spécification LN : Rusty Russell a posté sur la liste de diffusion Lightning-Dev un lien vers un PR où il propose de supprimer certaines fonctionnalités qui ne sont plus prises en charge par les implémentations LN modernes et de supposer que d’autres fonctionnalités seront toujours prises en charge. En lien avec les changements proposés, Russell fournit également les résultats d’une enquête qu’il a menée sur les fonctionnalités des nœuds publics en fonction de leurs messages de gossip. Ses résultats indiquent que presque tous les nœuds prennent en charge les fonctionnalités suivantes :

    • ● Messages d’oignon de taille variable : intégrés à la spécification en 2019 (voir Newsletter #58), à peu près en même temps que la spécification, a été mis à jour pour utiliser des champs Type-Length-Value (TLV). Cela a remplacé le format original pour le routage oignon chiffré qui nécessitait que chaque saut utilise un message de longueur fixe et limitait le nombre de sauts à 20. Le format de taille variable facilite beaucoup le relais de données arbitraires vers des sauts spécifiques, le seul inconvénient étant que la taille globale du message reste constante, de sorte que toute augmentation de la quantité de données envoyées diminue le nombre maximum de sauts.

    • ● Requêtes de gossip : intégrées à la spécification en 2018 (voir BOLTs #392). Cela permet à un nœud de demander à ses pairs uniquement un sous-ensemble des messages de gossip envoyés par d’autres nœuds sur le réseau. Par exemple, un nœud peut demander uniquement les mises à jour de gossip récentes, en ignorant les mises à jour plus anciennes pour économiser la bande passante et réduire le temps de traitement.

    • ● Protection contre la perte de données : intégrée à la spécification en 2017 (voir BOLTs #240). Les nœuds utilisant cette fonctionnalité envoient des informations sur leur dernier état de canal lorsqu’ils se reconnectent. Cela peut permettre à un nœud de détecter qu’il a perdu des données, et cela encourage un nœud qui n’a pas perdu de données à fermer le canal dans son dernier état. Voir Newsletter #31 pour des détails supplémentaires.

    • ● Clés de partie distante statiques : intégrées à la spécification en 2019 (voir Newsletter #67), cela permet à un nœud de demander que chaque mise à jour de canal s’engage à envoyer les fonds non-HTLC du nœud à la même adresse. Auparavant, une adresse différente était utilisée à chaque mise à jour de canal. Après ce changement, un nœud qui a opté pour ce protocole et qui a perdu des données recevra presque toujours à un moment donné au moins une partie de ses fonds à l’adresse choisie, comme une adresse dans son portefeuille HD.

    Les premières réponses au PR de proposition de nettoyage ont été positives.

En attente de confirmation #9 : Propositions de politique

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

Le post de la semaine dernière a décrit les sorties d’ancrage et l’exclusion CPFP, garantissant à chaque partie du canal la possibilité d’augmenter les frais de leurs transactions d’engagement partagées sans nécessiter de collaboration. Cette approche présente encore quelques inconvénients : les fonds du canal sont bloqués pour créer des sorties d’ancrage, les frais des transactions d’engagement sont généralement surestimés pour s’assurer qu’ils atteignent les frais minimaux du mempool, et l’exclusion CPFP ne permet qu’un seul descendant supplémentaire. Les sorties d’ancrage ne peuvent pas garantir la même capacité d’augmentation des frais pour les transactions partagées entre plus de deux parties, telles que les coinjoins ou les protocoles de contrat multi-parties. Ce post explore les efforts actuels pour remédier à ces limitations et à d’autres.

Package relay comprend un protocole P2P et des modifications de politique pour permettre le transport et la validation de groupes de transactions. Cela permettrait à une transaction d’engagement d’augmenter les frais même si la transaction d’engagement ne respecte pas le taux de frais minimal du mempool. De plus, Package RBF permettrait au descendant qui augmente les frais de payer pour remplacer les transactions en conflit avec son parent. Package relay est conçu pour éliminer une limitation générale au niveau du protocole de base. Cependant, en raison de son utilité pour l’augmentation des frais des transactions partagées, il a également donné lieu à plusieurs efforts pour éliminer l’épinglage pour des cas d’utilisation spécifiques. Par exemple, Package RBF permettrait aux transactions d’engagement de se remplacer mutuellement lorsqu’elles sont diffusées avec leurs descendants qui augmentent les frais, éliminant ainsi le besoin de plusieurs sorties d’ancrage sur chaque transaction d’engagement.

Un inconvénient est que les règles RBF existantes exigent que la transaction de remplacement paie des frais absolus plus élevés que les frais totaux payés par toutes les transactions à remplacer. Cette règle aide à prévenir les attaques de type DoS par des remplacements répétés, mais permet à un utilisateur malveillant d’augmenter le coût de remplacement de sa transaction en attachant un descendant avec des frais élevés mais un taux de frais faible. Cela empêche la transaction d’être extraite en empêchant injustement son remplacement par un package à frais élevés, et est souvent appelé “épinglage de la règle 3”.

Les développeurs ont également proposé des moyens totalement différents d’ajouter des frais aux transactions pré-signées. Par exemple, la signature des entrées de la transaction en utilisant SIGHASH_ANYONECANPAY | SIGHASH_ALL pourrait permettre au diffuseur de la transaction de fournir des frais en ajoutant des entrées supplémentaires à la transaction sans modifier les sorties. Cependant, comme RBF n’a aucune règle exigeant que la transaction de remplacement ait un “score minier” plus élevé (c’est-à-dire qu’elle serait sélectionnée plus rapidement pour un bloc), un attaquant pourrait épingler ces types de transactions en créant des remplacements encombrés par des ancêtres à faible taux de frais. Ce qui complique l’évaluation précise du score de minage des transactions et des packages de transactions, c’est que les limites existantes des ascendants et des descendants sont insuffisantes pour limiter la complexité computationnelle de ce calcul. Toutes les transactions connectées peuvent influencer l’ordre dans lequel les transactions sont sélectionnées pour être incluses dans un bloc. Un composant entièrement connecté, appelé un cluster, peut avoir n’importe quelle taille compte tenu des limites actuelles des ascendants et des descendants.

Une solution à long terme pour remédier à certaines lacunes du mempool et aux attaques d’épinglage RBF consiste à restructurer la structure de données du mempool pour suivre les clusters au lieu de simplement les ensembles d’ancêtres et de descendants. Ces clusters seraient limités en taille. Une limite de cluster restreindrait la manière dont les utilisateurs peuvent dépenser des UTXO non confirmés, mais permettrait de linéariser rapidement l’ensemble du mempool en utilisant l’algorithme de minage basé sur le score des ascendants, de construire des modèles de bloc extrêmement rapidement, et d’exiger que les transactions de remplacement aient un score de minage plus élevé que la ou les transactions à remplacer.

Même ainsi, il est possible qu’aucun ensemble unique de politiques ne puisse répondre à la large gamme de besoins et d’attentes en matière de relais de transactions. Par exemple, bien que les destinataires d’une transaction de paiement groupé bénéficient de la possibilité de dépenser leurs sorties non confirmées, une limite de descendant plus souple laisse place à l’épinglage du package RBF d’une transaction partagée par des frais absolus. Une proposition pour la politique de relais de transactions v3 a été développée pour permettre aux protocoles de contrat d’opter pour un ensemble plus restrictif de limites de package. Les transactions V3 ne permettraient que des packages de taille deux (un parent et un enfant) et limiteraient le poids de l’enfant. Ces limites atténueraient l’épinglage RBF par des frais absolus et offriraient certains avantages du mempool en cluster sans nécessiter une restructuration du mempool.

Les Ancres Éphémères s’appuient sur les propriétés des transactions V3 et du relais de packages pour améliorer davantage les sorties d’ancrage. Elles exemptent les sorties d’ancrage appartenant à une transaction V3 à frais nuls de la limite de poussière, à condition que la sortie d’ancrage soit dépensée par un descendant qui augmente les frais. Étant donné que la transaction sans frais doit être augmentée de frais par exactement un descendant (sinon un mineur ne serait pas incité à l’inclure dans un bloc), cette sortie d’ancrage est “éphémère” et ne fera pas partie de l’ensemble UTXO. La proposition d’ancres éphémères empêche implicitement les sorties autres que les sorties d’ancrage d’être dépensées lorsqu’elles ne sont pas confirmées sans verrouillages temporels 1 OP_CSV, puisque le seul descendant autorisé doit dépenser la sortie d’ancrage. Cela rendrait également la symétrie LN réalisable avec CPFP en tant que mécanisme de provisionnement des frais pour les transactions de fermeture de canal. Cela rend également ce mécanisme disponible pour les transactions partagées entre plus de deux participants. Les développeurs ont utilisé bitcoin-inquisition pour déployer les Ancres Éphémères et ont proposé des soft forks pour construire et tester ces changements multi-couches sur un signet.

Les problèmes d’épinglage mis en évidence dans ce post, entre autres, ont donné lieu à une multitude de discussions et de propositions pour améliorer la politique RBF l’année dernière, sur les listes de diffusion, les PR, les réseaux sociaux et les réunions en personne. Les développeurs ont proposé et mis en œuvre des solutions allant de petites modifications à une refonte complète. L’option -mempoolfullrbf, destinée à résoudre les problèmes d’épinglage et les divergences dans les implémentations de BIP125, a mis en évidence la difficulté et l’importance de la collaboration dans la politique de relais de transactions. Bien qu’un véritable effort ait été fait pour impliquer la communauté en utilisant des moyens habituels, notamment en lançant la conversation sur la liste de diffusion bitcoin-dev un an à l’avance, il était clair que les méthodes de communication et de prise de décision existantes n’avaient pas produit le résultat escompté et nécessitaient des améliorations.

La prise de décision décentralisée est un processus complexe, mais nécessaire pour soutenir l’écosystème diversifié des protocoles et des applications qui utilisent le réseau de relais de transactions de Bitcoin. La semaine prochaine, nous publierons notre dernier post de cette série, dans lequel nous espérons encourager nos lecteurs à participer et à améliorer ce processus.

Bitcoin Core PR Review Club

Dans cette section mensuelle, nous résumons une récente réunion du Club de révision des PR de Bitcoin Core en mettant en évidence certaines des questions et réponses importantes. Cliquez sur une question ci-dessous pour voir un résumé de la réponse de la réunion.

Arrêter de relayer les txs non-mempools est une PR de Marco Falke (MarcoFalke) qui simplifie le client Bitcoin Core en supprimant une structure de données en mémoire, mapRelay, qui peut causer une consommation élevée de mémoire et n’est plus nécessaire, ou du moins n’apporte que des avantages marginaux. Cette carte contient des transactions qui peuvent ou non être également dans le mempool, et est parfois utilisée pour répondre aux demandes getdata des pairs.

  • Quelles sont les raisons de supprimer mapRelay?

    La consommation de mémoire de cette structure de données est illimitée. Bien qu’elle n’utilise généralement pas beaucoup de mémoire, il est préoccupant lorsque la taille de toute structure de données est déterminée par le comportement d’entités externes (pairs) et n’a pas de maximum, car cela peut créer une vulnérabilité DoS. ➚

  • Pourquoi la consommation de mémoire de mapRelay est-elle difficile à déterminer?

    Chaque entrée dans mapRelay est un pointeur partagé vers une transaction (CTransaction), le mempool pouvant également contenir un autre pointeur. Un deuxième pointeur vers le même objet utilise très peu d’espace supplémentaire par rapport à un seul pointeur. Si une transaction partagée est supprimée du mempool, tout son espace devient attribuable à l’entrée mapRelay. Ainsi, l’utilisation de la mémoire de mapRelay ne dépend pas seulement du nombre de transactions et de leurs tailles individuelles, mais aussi du nombre de transactions qui ne sont plus dans le mempool, ce qui est difficile à prévoir. ➚

  • Quel problème est résolu en introduisant m_most_recent_block_txs? (Il s’agit d’une liste des transactions uniquement dans le bloc le plus récemment reçu.)

    Sans cela, puisque mapRelay n’est plus disponible, nous ne pourrions pas servir les transactions nouvellement extraites (dans le bloc le plus récent) aux pairs qui les demandent, car nous les aurions supprimées de notre mempool. ➚

  • Pensez-vous qu’il est nécessaire d’introduire m_most_recent_block_txs, plutôt que de simplement supprimer mapRelay sans le remplacer?

    Il y avait une certaine incertitude parmi les participants du club de révision concernant cette question. Il a été suggéré que m_most_recent_block_txs pourrait améliorer la vitesse de propagation des blocs, car si notre pair n’a pas encore le bloc que nous venons de recevoir, la capacité de notre nœud à fournir ses transactions peut aider à compléter notre pair avec le bloc compact. Une autre suggestion était que cela pourrait aider en cas de division de la chaîne ; si notre pair est sur un point différent du nôtre, il se peut qu’il n’ait pas cette transaction via un bloc. ➚

  • Quelles sont les exigences de mémoire pour m_most_recent_block_txs par rapport à mapRelay?

    Le nombre d’entrées dans m_most_recent_block_txs est limité par le nombre de transactions dans un bloc. Mais l’exigence de mémoire est encore inférieure à celui de nombreuses transactions, car les entrées de m_most_recent_block_txs sont des pointeurs partagés (vers des transactions), et ils sont également (déjà) pointés par m_most_recent_block. ➚

  • Y a-t-il des scénarios dans lesquels les transactions seraient disponibles pendant une durée plus courte ou plus longue qu’auparavant en raison de ce changement?

    Plus longtemps lorsque le temps écoulé depuis le dernier bloc est supérieur à 15 minutes (qui est le temps pendant lequel les entrées restaient dans mapRelay), sinon plus court. Cela semble acceptable car le choix du délai de 15 minutes était plutôt arbitraire. Mais le changement peut réduire la disponibilité des transactions en cas de divisions de chaînes supérieures à un bloc de profondeur (qui sont extrêmement rares) car nous ne conservons pas les transactions qui sont uniques aux chaînes moins longues. ➚

Mises à jour et verions 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 v0.16.4-beta est une version de maintenance de ce logiciel de nœud LN qui corrige une fuite de mémoire qui peut affecter certains utilisateurs.

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.

  • ● Bitcoin Core #27869 émet un avertissement de dépréciation lors du chargement d’un portefeuille hérité dans le cadre des efforts continus décrits dans Bitcoin Core #20160 pour aider les utilisateurs à migrer des portefeuilles hérités vers des portefeuilles descripteurs comme mentionné dans les bulletins d’information #125, #172 et #230.