Bitcoin Optech – Bulletin #246

Bulletin d’information hebdomadaire Bitcoin Optech du 12 avril 2023 traduit par @copinmalin.

Le bulletin de cette semaine rapporte une discussion à propos du splicing sur LN et une proposition de BIP sur la terminologie des transactions. Vous y trouverez également nos sections habituelles avec le résumé d’une réunion du Bitcoin Core PR Review Club, des annonces de nouvelles versions et de versions candidates—y compris une mise à jour de sécurité pour libsecp256k1—et des descriptions de changements notables apportés aux principaux logiciels de l’infrastructure Bitcoin.

Nouvelles

Discussions sur les spécifications du splicing : Plusieurs développeurs LN ont posté sur la liste de diffusion Lightning-Dev cette semaine à propos du travail en cours sur le projet de spécification pour le splicing, qui permet à certains fonds dans un canal LN hors chaîne d’être dépensés sur la chaîne (splice-out) ou à des fonds sur la chaîne d’être ajoutés à un canal hors chaîne (splice-in). Le canal peut continuer à fonctionner pendant qu’une transaction « splicée » sur la chaîne attend un nombre suffisant de confirmations.

• Les discussions de cette semaine ont portées sur les sujets suivants :
  • Quelles signatures d’engagement envoyer ? Lorsqu’un splicing est créé, un nœud contient des transactions d’engagement parallèles, une qui dépense à partir de la sortie de financement originale et une qui dépense à partir de chaque nouvelle sortie de financement pour tous les splicing en attente. Chaque fois que l’état du canal est mis à jour, toutes les transactions d’engagements parallèles doivent être mises à jour. La façon la plus simple de gérer cela est d’envoyer les mêmes messages que ceux qui seraient envoyés pour une transaction d’engagement individuelle, mais en les répétant, un pour chaque transaction d’engagement parallèle.
    C’est ce qui a été fait dans le projet initial de spécifications pour le splicing (voir les bulletins #17 et #146). Cependant, comme Lisa Neigut l’a expliqué cette semaine, la création d’un nouveau splicing nécessite la signature de la nouvelle transaction d’engagement dérivée. Dans le projet de spécification actuel, l’envoi d’une signature nécessite l’envoi des signatures pour toutes les autres transactions d’engagement en cours. C’est redondant : les signatures de ces autres transactions d’engagement ont déjà été envoyées. En outre, dans le protocole LN actuel, chaque partie reconnaît avoir reçu une signature de sa contrepartie en envoyant le point de révocation de la transaction d’engagement précédente. Là encore, cette information a déjà été envoyée. Il n’est pas dangereux de renvoyer les signatures et les anciens points de révocation, mais cela nécessite une bande passante et un traitement supplémentaires. L’avantage est que l’exécution de la même opération dans tous les cas contribue à la simplicité de la spécification, ce qui peut réduire la complexité de la mise en œuvre et des tests.
    L’autre solution consiste à n’envoyer que le nombre minimum de signatures pour la nouvelle transaction d’engagement lorsqu’un nouveau fractionnement est négocié, ainsi qu’un accusé de réception. Cette solution est beaucoup plus efficace, même si elle ajoute un peu de complexité. Il convient de noter que les nœuds LN ne doivent gérer des transactions d’engagement parallèles que jusqu’à ce qu’une transaction de jonction ait été confirmée à un niveau suffisant pour que les deux contreparties la considèrent comme sûre. Ensuite, ils peuvent revenir à une transaction d’engagement unique.
  • Quantités relatives et splicing zéro-conf : Bastien Teinturier a posté à propos de plusieurs propositions de mise à jour de la spécification. En plus de la modification des signatures d’engagement mentionnée ci-dessus, il recommande également que les propositions des splicing utilisent des quantités relatives, par exemple “200 000 sats” indique qu’Alice veut séparer cette quantité et “-50 000 sats” indique qu’elle veut joindre cette quantité. Il mentionne également un problème concernant les splicing “zero-conf”, mais n’entre pas dans les détails.
• Proposition de BIP pour la terminologie des transactions : Mark “Murch” Erhardt a posté le projet d’un BIP informatif sur la liste de diffusion Bitcoin-Dev qui suggère un vocabulaire à utiliser pour se référer aux parties des transactions et aux concepts qui s’y rapportent. À l’heure où nous écrivons ces lignes, toutes les réponses à la proposition sont favorables à l’effort.

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.

Ne pas télécharger de témoins pour les blocs supposés valides lorsque l’on fonctionne en mode “prune” est un PR de Niklas Gögge (dergoegge) qui améliore les performances du téléchargement de bloc initial (IBD) en ne téléchargeant pas les données témoins sur les nœuds qui sont configurés à la fois pour élaguer les données des blocs et pour utiliser assumevalid. Cette optimisation a été discutée dans une récente question sur stack exchange.

• Si assume-valid est activé mais pas l’élagage, pourquoi le nœud doit-il télécharger des données de témoins (non récentes), étant donné que le nœud ne vérifiera pas ces données ? Cette PR devrait-elle également désactiver le téléchargement des témoins dans ce cas de non-élagage ?
• Quelle quantité de bande passante cette amélioration pourrait-elle permettre d’économiser au cours d’un IBD ? En d’autres termes, quelle est la taille cumulée de toutes les données témoins jusqu’à un bloc récent (par exemple, la hauteur 781213) ?
• Cette amélioration permettrait-elle de réduire la quantité de données téléchargées de tous les blocs vers le bloc Genesis ?
• Ce PR met en œuvre deux changements principaux, l’un concernant la logique de demande de bloc et l’autre la validation des blocs. Quels sont ces changements en détail ?
• Sans ce PR, la validation des scripts est ignorée sous assume-valid, mais les autres contrôles qui impliquent des données témoins ne sont pas ignorés. Quelles sont les vérifications que cette PR fera ignorer ?
• Le PR n’inclut pas de modification explicite du code permettant d’ignorer toutes les vérifications supplémentaires mentionnées dans la question précédente. Pourquoi cela fonctionne-t-il ?