Bulletin hebdomadaire Bitcoin Optech #271

Bulletin d’information hebdomadaire Bitcoin Optech du 4 octobre 2023 traduit par @copinmalin.

Le bulletin de cette semaine résume une proposition pour contrôler à distance les nœuds LN à l’aide d’un dispositif de signature matériel, décrit des recherches axées sur la confidentialité et du code permettant aux nœuds de transmission de diviser dynamiquement les paiements LN, et examine une proposition visant à améliorer la liquidité LN en permettant à des groupes de nœuds de transfert de regrouper des fonds séparément de leurs canaux normaux. Sont également incluses nos sections régulières 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

• Contrôle à distance sécurisé des nœuds LN : Bastien Teinturier a publié sur la liste de diffusion Lightning-Dev une proposition BLIP qui spécifierait comment un utilisateur pourrait envoyer des commandes signées à son nœud LN à partir d’un dispositif de signature matériel (ou de tout autre portefeuille). Le dispositif de signature n’aurait besoin de mettre en œuvre que le BLIP plus la communication entre pairs BOLT8 et le nœud LN n’aurait besoin de mettre en œuvre que le BLIP. Cela ressemble au plugin commando de Core Lightning (voir Bulletin #210), qui permet un contrôle presque complet à distance d’un nœud LN, mais Bastien Teinturier envisage sa fonctionnalité principalement pour le contrôle des actions de nœud les plus sensibles, telles que l’autorisation d’un paiement—le type d’actions pour lesquelles un utilisateur serait raisonnablement prêt à passer par la peine de connecter et de déverrouiller un dispositif de sécurité matériel, puis d’autoriser l’action. Cela faciliterait la sécurisation du solde LN d’un utilisateur avec le même niveau de sécurité de dispositif de signature matériel que son solde onchain.
• Division et commutation des paiements : Gijs van Dam a publié sur la liste de diffusion Lightning-Dev un plugin qu’il a écrit pour Core Lightning et des recherches qu’il a effectuées à ce sujet. Le plugin permet aux nœuds de transfert d’indiquer à leurs pairs qu’ils prennent en charge la division et la commutation des paiements (PSS). Si Alice et Bob partagent un canal et que tous deux prennent en charge le PSS, alors lorsque Alice reçoit un paiement à transférer à Bob, le plugin peut diviser ce paiement en deux ou plusieurs parties de paiement. L’un de ces paiements peut être transféré à Bob comme d’habitude, mais les autres peuvent suivre des chemins alternatifs (par exemple, d’Alice à Carol à Bob). Bob attend de recevoir toutes les parties, puis continue de transférer le paiement comme d’habitude vers le prochain saut.

  Le principal avantage de cette approche est qu’elle rend plus difficile l’exécution d’attaques de découverte de solde (BDA) où une tierce partie sonde de manière répétée un canal pour suivre son solde. Si cela est fait fréquemment, une BDA peut suivre le montant d’un paiement passant par un canal. Si cela est fait sur de nombreux canaux, il peut être possible de suivre ce paiement lorsqu’il traverse le réseau. Lorsque le PSS est utilisé, l’attaquant devrait suivre non seulement le solde du canal Alice-et-Bob, mais aussi celui du canal Alice-et-Carol et les canaux Carol-et-Bob. Même si l’attaquant suivait le solde de tous ces canaux, la difficulté de calcul pour suivre le paiement augmente, tout comme la possibilité que des parties des paiements d’autres utilisateurs qui passent simultanément par ces canaux puissent être confondues avec des parties du paiement original qui est suivi. Un article de van Dam a montré qu’un attaquant pouvait obtenir une réduction de 62% de la quantité d’informations lorsque PSS est déployé.

  Deux avantages supplémentaires sont mentionnés dans l’article de van Dam sur PSS : une augmentation du débit de LN et une partie d’atténuation contre les attaques de brouillage de canal. L’idée de PSS a fait l’objet d’une petite discussion sur la liste de diffusion à la date de rédaction de cet article.

• Liquidité mutualisée pour LN : ZmnSCPxj a proposé à la liste de diffusion Lightning-Dev une suggestion qu’il appelle des sidepools. Cela impliquerait des groupes de nœuds de transfert travaillant ensemble pour déposer des fonds dans un contrat d’état multiparties—un contrat hors chaîne (qui est ancré sur la chaîne de manière similaire à un canal LN) qui permettrait de déplacer des fonds entre les participants en mettant à jour l’état du contrat hors chaîne. Par exemple, un état initial qui donne à Alice, Bob et Carol chacun 1 BTC pourrait être mis à jour vers un nouvel état qui donne à Alice 2 BTC, Bob 0 BTC et Carol 1 BTC.

  Les nœuds de transfert continueraient également à utiliser et à annoncer des canaux LN ordinaires entre des paires de nœuds ; par exemple, les trois utilisateurs décrits précédemment pourraient avoir trois canaux distincts : Alice et Bob, Bob et Carol, et Alice et Carol. Ils transféreraient les paiements à travers ces canaux exactement de la même manière qu’ils le peuvent aujourd’hui.

  Si un ou plusieurs des canaux ordinaires devenaient déséquilibrés—par exemple, une trop grande partie des fonds dans le canal entre Alice et Bob appartient maintenant à Alice—le déséquilibre pourrait être résolu en effectuant un peerswap hors chaîne dans le contrat d’état. Par exemple, Carol pourrait fournir des fonds à Alice dans le contrat d’état à condition qu’Alice transfère la même quantité de fonds à travers Bob vers Carol dans le canal LN ordinaire—rétablissant l’équilibre dans le canal LN entre Alice et Bob.

  L’avantage de cette approche c’est que personne n’a besoin de connaître le contrat d’état à part les participants de chaque contrat particulier. Pour tous les utilisateurs LN ordinaires et tous les nœuds de transfert qui ne sont pas impliqués dans un contrat particulier, LN continue de fonctionner en utilisant le protocole actuel. Un autre avantage, par rapport aux opérations de rééquilibrage de canal existantes, c’est que l’approche du contrat d’état permet à un grand nombre de nœuds de transfert de maintenir une relation directe entre pairs pour une petite quantité d’espace sur la chaîne, éliminant ainsi probablement les frais de rééquilibrage hors chaîne entre ces pairs. Le maintien de frais de rééquilibrage minimaux aide grandement les nœuds de transfert à maintenir l’équilibre de leurs canaux, ce qui améliore leur potentiel de revenus et rend l’envoi de paiements à travers LN plus fiable.

  L’inconvénient de cette approche c’est qu’elle nécessite un contrat d’état multiparties, ce qui n’a jamais été mis en œuvre en production jusqu’à notre connaissance. ZmnSCPxj mentionne deux protocoles de contrat qui pourraient être utiles à utiliser comme base, LN-Symmetry et duplex payment channels. LN-Symmetry nécessiterait un changement de consensus, ce qui semble peu probable dans un avenir proche, c’est pourquoi un article de suivi de ZmnSCPxj semble se concentrer sur les canaux de paiement duplex (que ZmnSCPxj appelle “Decker-Wattenhofer” d’après les chercheurs qui les ont proposés en premier). Le problème avec les canaux de paiement duplex c’est qu’ils ne peuvent pas rester ouverts indéfiniment, bien que l’analyse de ZmnSCPxj indique qu’ils peuvent probablement rester ouverts suffisamment longtemps, et à travers suffisamment de changements d’état, pour amortir leur coût de manière efficace.

  Il n’y a eu aucune réponse publique aux articles au moment de la rédaction, bien que nous ayons appris dans une correspondance privée avec ZmnSCPxj qu’il travaille à développer davantage l’idée.

Mises à jour et versions candidates

• LND v0.17.0-beta est la version pour la prochaine version majeure de cette implémentation populaire de nœud LN. Une nouvelle fonctionnalité expérimentale majeure incluse dans cette version est la prise en charge des “canaux taproot simples”, ce qui permet d’utiliser des canaux non annoncés financés onchain à l’aide d’une sortie P2TR. Il s’agit de la première étape vers l’ajout d’autres fonctionnalités aux canaux de LND, telles que la prise en charge des Taproot Assets et des PTLC. La version inclut également une amélioration significative des performances pour les utilisateurs du backend Neutrino, qui prend en charge les filtres de bloc compacts, ainsi que des améliorations de la fonctionnalité watchtower intégrée de LND. Pour plus d’informations, veuillez consulter les notes de version et le billet de blog de la version.

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.

• Eclair #2756 introduit la surveillance des opérations de splicing. Les métriques collectent l’initiateur de l’opération et distinguent trois types de splices : splice-in, splice-out et splice-cpfp.
• LDK #2486 ajoute la prise en charge du financement de plusieurs canaux dans une seule transaction, garantissant l’atomicité avec soit tous les canaux groupés financés et ouverts, soit tous fermés.
• LDK #2609 permet de demander les descripteurs utilisés pour recevoir des paiements dans des transactions passées. Auparavant, les utilisateurs devaient les stocker eux-mêmes ; avec l’API mise à jour, les descripteurs peut être reconstruit à partir d’autres données stockées.