Bitcoin Optech – Bulletin #221

Traduction du 221e bulletin d’information hebdomadaire de Bitcoin Optech par @copinmalin.

12 octobre 2022

La newsletter de cette semaine résume une proposition visant à permettre aux utilisateurs occasionnels de LN de rester hors ligne jusqu’à plusieurs mois d’affilée et décrit un document permettant aux serveurs d’information sur les transactions d’héberger des adresses de portefeuilles inutilisées. Vous trouverez également nos sections habituelles avec le résumé d’un Bitcoin Core PR Review Club, des annonces de nouvelles versions de logiciels et de release candidate (y compris un correctif critique pour le LN), et les principaux changements apportés aux logiciels d’infrastructure Bitcoin.

Nouvelles

• LN avec une proposition de hors ligne long : John Law a posté sur la liste de diffusion Lightning-Dev une proposition pour permettre aux utilisateurs occasionnels de Lightning de rester hors ligne jusqu’à plusieurs mois sans risquer de perdre des fonds avec leurs partenaires de canaux. Bien que cela soit techniquement possible dans le protocole LN actuel, cela dépendrait de la définition du paramètre ‘settlement-delay’ à des valeurs élevées qui permettraient à un utilisateur malheureux ou à un accident d’empêcher les fonds de plus d’une douzaine de canaux d’être utilisés pour ces mêmes mois. Law propose de mitiger ce problème à travers deux modifications du protocole:
  • Triggered HTLCs : Dans une norme HTLC utilisée pour le paiement, Alice offre à Bob une certaine quantité de BTC s’il est capable de publier une préimage inconnue auparavant pour un condensé de hachage connu. Alternativement, si Bob ne publie pas la préimage avant un certain temps, Alice peut retourner l’argent dans son propre portefeuille. Law suggère que Bob soit toujours autorisé à réclamer le paiement à tout moment avec la publication de la préimage, mais Alice devrait remplir une restriction supplémentaire. Elle devrait clairement avertir Bob de son intention de récupérer l’argent dans son portefeuille en faisant confirmer une transaction trigger sur la chaîne. Ce n’est que lorsque la transaction de déclenchement aura été confirmée par un certain nombre de blocs (ou pendant une certaine durée) qu’Alice pourra dépenser l’argent. Bob serait assuré de pouvoir réclamer ses fonds à tout moment jusqu’à ce que la transaction de déclenchement ait reçu le nombre convenu de confirmations, même si des mois se sont écoulés depuis qu’un HTLC normal aurait expiré. Si Bob est correctement indemnisé pour son attente, il n’y a pas de problème si Alice reste hors ligne pendant tout ce temps. Pour un HTLC acheminé d’Alice vers un nœud distant en passant par Bob, seul le canal entre Alice et Bob serait affecté—-tous les autres canaux régleraient le HTLC rapidement (comme dans le protocole LN actuel).
  • Asymmetric delayed commitment transactions : chacun des deux partenaires d’un canal LN détient un engagement non publié qu’ils peuvent publier et essayer de faire confirmer à tout moment. Les deux versions de la transaction dépensent le même UTXO, de sorte qu’elles entrent en conflit l’une avec l’autre. Ce qui signifie qu’une seule peut effectivement être confirmée. Cela signifie que quand Alice veut fermer le canal, elle ne peut pas juste simplement diffuser sa version de la transaction d’engagement avec un délai raisonnable et supposer qu’elle sera confirmée. Elle doit aussi attendre et vérifier si Bob obtient au contraire sa version de la transaction d’engagement, auquel cas elle devra peut-être avoir besoin de prendre des mesures supplémentaires pour vérifier que sa transaction inclut le dernier état du canal. Law propose que la version d’Alice de la transaction d’engagement reste la même qu’aujourd’hui afin qu’elle puisse la publier à tout moment, mais que la version de Bob comprenne un verrou temporel afin qu’il ne puisse la publier que si Alice a été inactive pendant une longue période. Idéalement, cela permet à Alice de publier le dernier état en sachant que Bob ne peut pas publier une version contradictoire, ce qui lui permet de se déconnecter en toute sécurité après sa publication. Les propositions de Law recevaient encore un premier retour d’information au moment où cette description était rédigée.
• Recommandations pour les serveurs d’adresses uniques : Ruben Somsen a posté sur la liste de diffusion Bitcoin-Dev un document avec une autre suggestion sur la façon dont les utilisateurs peuvent éviter un output linking sans faire confiance à un service tiers ou utiliser un protocole cryptographique qui n’est pas largement pris en charge actuellement, comme le BIP47 ou silent payments. La méthode recommandée est particulièrement destinée aux portefeuilles qui fournissent déjà leurs adresses à des tiers, comme ceux qui utilisent des serveurs publics de recherche d’adresses (ce qui est censé être la majorité des portefeuilles légers). Pour illustrer le fonctionnement de cette méthode, le portefeuille d’Alice enregistre 100 adresses sur le serveur Example.com de style electrum. Elle inclut ensuite « example.com/alice » dans sa signature de courriel. Lorsque Bob veut donner de l’argent à Alice, il visite son URL, obtient une adresse, vérifie qu’Alice l’a signée, puis effectue le paiement. Cette idée présente l’avantage d’être largement compatible avec de nombreux portefeuilles grâce à un processus partiellement manuel et peut être facile à mettre en œuvre avec un processus automatisé. Son inconvénient est que les utilisateurs qui compromettent déjà leur vie privée en partageant des adresses avec un serveur s’engageront davantage dans la perte de confidentialité. La discussion sur les suggestions était en cours à la fois sur la liste de diffusion et sur le document au moment de la rédaction de ce résumé.

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.

Fabriquer des connexions AddrFetch pour fixer les seeds est une PR de Martin Zumsande qui établit des connexions AddrFetch vers les fixed seeds (adresses IP codées en dur) au lieu de simplement les ajouter à AddrMan (la base de données de nos pairs).

• Lorsqu’un nouveau nœud démarre à partir de zéro, il doit d’abord se connecter à certains pairs à partir desquels il effectuera le téléchargement du bloc initial (IBD). Dans quelles circonstances se connecte-t-il aux fixed seeds ?
• Quel changement de comportement observable cette PR introduit-elle ? Quels types d’adresses ajoutons-nous à AddrMan, et dans quelles circonstances?
• Pourquoi voudrions-nous établir une connexion AddrFetch au lieu d’une connexion sortante complète vers des graines fixes?
• Les nœuds DNS d’amorçage sont censés être réactifs et servir les adresses actualisées des nœuds Bitcoin. Pourquoi cela n’aide-t-il pas un noeud -onlynet=tor ?

Mises à jour release candidate