Le bulletin de cette semaine résume une discussion sur l’autorisation de relayer les transactions contenant des données dans le champ annexe taproot et des liens vers un projet de BIP pour les paiements silencieux. Vous trouverez également une nouvelle contribution à notre série hebdomadaire limitée sur la politique mempool, ainsi que nos sections habituelles résumant une réunion du Bitcoin Core PR Review Club, annonçant les nouvelles versions de logiciels et les versions candidates, et décrivant les principaux changements apportés aux logiciels d’infrastructure Bitcoin les plus répandus.

Nouvelles

• ● Discussion sur les annexes à taproot : JJoost Jager a posté sur la liste de diffusion Bitcoin-Dev une demande de modification du relais de transaction et de la politique de minage de Bitcoin Core afin de permettre le stockage de données arbitraires dans le champ annexe taproot. Ce champ est une partie optionnelle des données du témoin pour les transactions taproot. S’il est présent, les signatures dans taproot et tapscript doivent s’engager sur ses données (ce qui rend impossible l’ajout, la suppression ou la modification par un tiers), mais il n’a pas d’autre objectif défini pour l’instant—il est réservé aux futures mises à jour du protocole, en particulier aux soft forks.

  Bien qu’il y ait eu des propositions antérieures pour définir un format pour l’annexe, elles n’ont pas été largement acceptées et mises en œuvre. Jager a proposé deux formats (1, 2) qui pourraient être utilisés pour permettre à quiconque d’ajouter des données arbitraires à l’annexe d’une manière qui ne compliquerait pas de manière significative les efforts de normalisation ultérieurs qui pourraient être regroupés avec un soft fork.

  Greg Sanders a répondu pour demander quelles données Jager voulait spécifiquement stocker dans l’annexe et a décrit sa propre utilisation de l’annexe en testant le protocole LN-Symmetry avec la proposition de soft fork SIGHASH_ANYPREVOUT à l’aide de Bitcoin Inquisition (voir le Bulletin d’information #244). Sanders a également décrit un problème avec l’annexe : dans un protocole multipartite (comme un coinjoin), chaque signature n’engage que l’annexe pour l’entrée contenant cette signature—et non les annexes pour d’autres entrées dans la même transaction. Cela signifie que si Alice, Bob et Mallory signent ensemble une coinjoin, Alice et Bob n’ont aucun moyen d’empêcher Mallory de diffuser une version de la transaction avec une annexe importante qui retarde sa confirmation. Étant donné que Bitcoin Core et d’autres nœuds complets ne relaient pas actuellement les transactions contenant des annexes, ce problème ne se pose pas pour l’instant. Jager a répondu qu’il souhaite stocker des signatures à partir de clés éphémères pour un type de coffre-fort qui ne nécessite pas de soft fork, et il a suggéré que certains travaux antérieurs dans Bitcoin Core pourraient éventuellement résoudre le problème du relais des annexes dans certains protocoles multipartites.

• ● Projet de BIP pour les paiements silencieux : Josie Baker et Ruben Somsen ont posté sur la liste de diffusion Bitcoin-Dev un projet de BIP pour les paiements silencieux, un type de code de paiement réutilisable qui produira une adresse unique sur la chaîne à chaque fois qu’il sera utilisé, empêchant ainsi la liaison des sorties. La liaison des sorties peut réduire de manière significative la vie privée des utilisateurs (y compris les utilisateurs qui ne sont pas directement impliqués dans une transaction). Le projet détaille les avantages de la proposition, ses inconvénients et la manière dont les logiciels peuvent l’utiliser efficacement. Plusieurs commentaires intéressants ont déjà été postés sur le PR pour le BIP.

En attente de confirmation #5 : Politique de protection des ressources des nœuds

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 le plus efficacement possible.

Nous avons commencé notre série en affirmant qu’une grande partie de la résistance de Bitcoin à la vie privée et à la censure découle de la nature décentralisée du réseau. La pratique selon laquelle les utilisateurs gèrent leurs propres nœuds réduit les points centraux de défaillance, de surveillance et de censure. Il s’ensuit que l’un des principaux objectifs de conception du logiciel de nœud Bitcoin est l’accessibilité élevée de l’exploitation d’un nœud. Exiger de chaque utilisateur de Bitcoin qu’il achète du matériel coûteux, qu’il utilise un système d’exploitation spécifique ou qu’il dépense des centaines de dollars par mois en frais d’exploitation réduirait très probablement le nombre de nœuds sur le réseau.

Par ailleurs, un nœud du réseau Bitcoin est un ordinateur connecté à des entités inconnues qui peuvent lancer une attaque par déni de service (DoS) en créant des messages qui font que le nœud manque de mémoire et tombe en panne, ou qu’il dépense ses ressources informatiques et sa bande passante pour des données sans intérêt au lieu d’accepter de nouveaux blocs. Comme ces entités sont anonymes de par leur conception, les nœuds ne peuvent pas déterminer à l’avance si un pair sera honnête ou malveillant avant de se connecter, et ne peuvent pas l’interdire efficacement même après qu’une attaque a été observée. La mise en œuvre de politiques de protection contre les attaques par déni de service et de limitation du coût de fonctionnement d’un nœud complet n’est donc pas seulement un idéal, c’est un impératif.

Des protections générales contre les attaques par déni de service sont intégrées dans les implémentations des nœuds afin d’éviter l’épuisement des ressources. Par exemple, si un nœud de Bitcoin Core reçoit de nombreux messages d’un seul pair, il ne traite que le premier et ajoute le reste à une file d’attente pour qu’il soit traité après les messages des autres pairs. En règle générale, un nœud télécharge d’abord l’en-tête d’un bloc et vérifie sa preuve de travail (PoW) avant de télécharger et de valider le reste du bloc. Ainsi, tout attaquant souhaitant épuiser les ressources de ce nœud par le biais d’un relais de bloc doit d’abord dépenser une quantité disproportionnée de ses propres ressources pour calculer une preuve de travail valide. L’asymétrie entre le coût énorme du calcul du PoW et le coût trivial de la vérification fournit un moyen naturel d’intégrer la résistance aux attaques par déni de service dans le relais de bloc. Cette propriété ne s’étend pas au relais de transactions non confirmées.

Les protections générales contre les attaques par déni de service n’offrent pas une résistance suffisante pour permettre au moteur de consensus d’un nœud d’être exposé à des données provenant du réseau pair-à-pair. Un attaquant tentant de fabriquer une transaction à forte intensité de calcul, validée par consensus, peut envoyer une transaction comme la “mégatransaction” de 1 Mo dans le bloc #364292, dont la validation a pris un temps anormalement long en raison de la vérification de la signature et de l’ajustement quadratique. Un attaquant peut également rendre toutes les signatures valides, sauf la dernière, ce qui amène le nœud à passer plusieurs minutes sur sa transaction, pour finalement découvrir qu’elle est inutile. Pendant ce temps, le nœud retarderait le traitement d’un nouveau bloc. On peut imaginer que ce type d’attaque vise des mineurs concurrents afin de prendre de l’avance sur le bloc suivant.

Afin d’éviter de travailler sur des transactions très coûteuses en termes de calcul, les nœuds de Bitcoin Core imposent une taille standard maximale et un nombre maximal d’opérations de signature (ou “sigops”) pour chaque transaction, ce qui est plus restrictif que la limite de consensus par bloc. Les nœuds de Bitcoin Core imposent également des limites sur la taille des paquets d’ancêtres et de descendants, ce qui rend les algorithmes de production et d’éviction de modèles de blocs plus efficaces et limite la complexité de calcul de l’insertion et de la suppression du mempool, qui nécessitent la mise à jour des ensembles d’ancêtres et de descendants d’une transaction. Bien que cela signifie que certaines transactions légitimes peuvent ne pas être acceptées ou relayées, ces transactions devraient être rares.

Ces règles sont des exemples de politique de relais de transaction, un ensemble de règles de validation en plus du consensus que les nœuds appliquent aux transactions non confirmées.

Par défaut, les nœuds de Bitcoin Core n’acceptent pas les transactions inférieures au taux de relais minimum de 1sat/vB (“minrelaytxfee”), ne vérifient pas les signatures avant de contrôler cette exigence et ne transmettent pas les transactions à leurs mempools à moins qu’elles ne soient acceptées. D’une certaine manière, cette règle de taux de frais fixe un “prix” minimum pour la validation et le relais du réseau. Un nœud non-mineur ne reçoit jamais de frais - ils sont uniquement payés au mineur qui confirme la transaction. Cependant, les frais représentent un coût pour l’attaquant. Quelqu’un qui “gaspille” les ressources du réseau en envoyant un nombre extrêmement élevé de transactions finit par manquer d’argent pour payer les frais.

La politique Replace by Fee mise en œuvre par Bitcoin Core exige que la transaction de remplacement paie des frais plus élevés que chaque transaction avec laquelle elle entre directement en conflit, mais aussi qu’elle paie des frais totaux plus élevés que toutes les transactions qu’elle remplace. Les frais supplémentaires divisés par la taille virtuelle de la transaction de remplacement doivent être d’au moins 1sat/vB. En d’autres termes, quels que soient les taux des transactions d’origine et de remplacement, la nouvelle transaction doit payer de “nouveaux” frais pour couvrir le coût de sa propre bande passante à 1sat/vB. Cette politique tarifaire n’est pas principalement axée sur la compatibilité des incitations. Il s’agit plutôt d’un coût minimum pour les remplacements répétés de transactions afin de limiter les attaques qui gaspillent la bande passante, par exemple en ajoutant seulement 1 satoshi supplémentaire à chaque remplacement.

Un nœud qui valide entièrement les blocs et les transactions nécessite des ressources, notamment de la mémoire, des ressources informatiques et de la bande passante. Les exigences en matière de ressources doivent rester faibles afin de rendre l’exploitation d’un nœud accessible et de défendre le nœud contre l’exploitation. Les protections générales contre les attaques par déni de service n’étant pas suffisantes, les nœuds appliquent des politiques de relais de transaction en plus des règles de consensus lorsqu’ils valident des transactions non confirmées. Toutefois, la politique n’étant pas un consensus, deux nœuds peuvent avoir des politiques différentes mais être d’accord sur l’état actuel de la chaîne. Le billet de la semaine prochaine traitera de la politique en tant que choix individuel.

Bitcoin Core PR Review Club

Dans cette section mensuelle, nous résumons une récente réunion du Bitcoin Core PR Review Club en soulignant 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.

Autoriser les connexions whitebind entrantes à évincer plus agressivement les pairs lorsque les slots sont pleins est une PR de Matthew Zipkin (pinheadmz) qui améliore dans certains cas la capacité d’un opérateur de nœud à configurer les pairs souhaités pour le nœud. Plus précisément, si l’opérateur du nœud a mis sur liste blanche un pair entrant potentiel (par exemple, un client léger contrôlé par l’opérateur du nœud), sans cette PR, et en fonction de l’état des pairs du nœud, il est possible que le nœud refuse la tentative de connexion de ce client léger.

Cette PR rend beaucoup plus probable la possibilité pour le pair désiré de se connecter à notre nœud. Pour ce faire, il évince un pair entrant existant qui, sans ce PR, n’aurait pas été éligible à l’éviction.

• Pourquoi cette PR ne s’applique-t-elle qu’aux demandes de pairs entrants ?

  Notre nœud initie les connexions sortantes ; ce PR modifie la façon dont le nœud réagit à une demande de connexion entrante. Les nœuds sortants peuvent être expulsés, mais cela se fait à l’aide d’un algorithme entièrement distinct. ➚

• Quel est l’impact du paramètre force de SelectNodeToEvict() sur la valeur de retour ?

  Spécifier force comme true assure qu’un pair entrant non noban est retourné, s’il existe, même s’il est autrement protégé contre l’expulsion. Sans le PR, aucun pair ne serait renvoyé s’ils sont tous exclus (protégés) de l’expulsion. ➚

• Comment la signature de la fonction EraseLastKElements() est-elle modifiée dans ce PR ?

  Elle est passée d’une fonction de retour void à une fonction de retour de la dernière entrée qui a été supprimée de la liste des candidats à l’éviction. (Ce nœud protégé peut être évincé si nécessaire). Cependant, suite à une discussion lors de la réunion du club de révision, le PR a été simplifié de telle sorte que cette fonction n’est plus modifiée. ➚

• EraseLastKElements était une fonction templatée, mais cette PR supprime les deux arguments template. Pourquoi ? Y a-t-il des inconvénients à ce changement ?

  Cette fonction était et (avec ce PR) est appelée avec des arguments de modèle uniques, il n’est donc pas nécessaire que la fonction soit modélisée. Les changements apportés par le PR à cette fonction ont été annulés, donc elle est toujours modélisée, parce que changer cela dépasserait le cadre du PR. ➚

• Supposons que nous passions un vecteur de 40 candidats à l’éviction à SelectNodeToEvict(). Avant et après cette PR, quel est le maximum théorique de noeuds Tor qui peuvent être protégés de l’éviction ?

  Avec et sans les relations publiques, le nombre serait de 34 sur 40, en supposant qu’il ne s’agisse pas de noban entrant. ➚

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.

• ● Core Lightning 23.05.1 est une version de maintenance pour cette implémentation de LN. Ses notes de publication indiquent que “cette version corrige uniquement les bogues qui réparent plusieurs crashs signalés dans la nature. Il s’agit d’une mise à jour recommandée pour tous ceux qui utilisent la version 23.05.”

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.

• ● Bitcoin Core #27501 ajoute une RPC getprioritizedtransactions qui renvoie une carte de tous les deltas de frais créés par l’utilisateur avec prioritisetransaction, indexés par txid. La carte indique également si chaque transaction est présente dans le mempool. Voir aussi Newsletter #250.

• ● Core Lightning #6243 met à jour la RPC listconfigs pour mettre toutes les informations de configuration dans un seul dictionnaire et transmet également l’état de toutes les options de configuration aux plugins redémarrés.

• ● Eclair #2677 augmente le max_cltv par défaut de 1 008 blocs (environ une semaine) à 2 016 blocs (environ deux semaines). Cela étend le nombre maximum de blocs autorisés jusqu’à ce qu’une tentative de paiement échoue. Ce changement est motivé par le fait que les noeuds du réseau augmentent leur fenêtre de temps réservée pour adresser un HTLC expirant (cltv_expiry_delta) en réponse à des taux élevés sur la chaîne. Des changements similaires ont été fusionnés avec LND et CLN.

• ● Rust bitcoin #1890 ajoute une méthode pour compter le nombre d’opérations de signature (sigops) dans les scripts non-tapscript. Le nombre de sigops est limité par bloc et le code de sélection des transactions de Bitcoin Core pour le minage traite les transactions avec un ratio élevé de sigops par taille (poids) comme s’il s’agissait de transactions plus importantes, ce qui réduit effectivement leur taux. Cela signifie qu’il peut être important pour les créateurs de transactions d’utiliser quelque chose comme cette nouvelle méthode pour vérifier le nombre de sigops qu’ils utilisent.