Bulletin hebdomadaire Bitcoin Optech #270

Bulletin d’information hebdomadaire Bitcoin Optech du 27 septembre 2023 traduit par @copinmalin.

Le bulletin de cette semaine décrit une proposition d’utilisation de covenants pour améliorer considérablement la scalabilité du Lightning Network. Elle comprend également nos rubriques habituelles avec des questions et réponses populaires de la communauté Bitcoin Stack Exchange, des annonces de nouvelles versions et versions candidates, ainsi que les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

• Utilisation de covenants pour améliorer la scalabilité de LN : John Law a publié sur les listes de diffusion Bitcoin-Dev et Lightning-Dev le résumé d’un article qu’il a écrit sur la création de très grandes usines à canaux en utilisant des covenants et la gestion des canaux résultants en utilisant des adaptations de plusieurs protocoles précédents qu’il a décrits (voir les bulletins #221, #230 et #244).
  
  Il commence par décrire un problème de scalabilité avec les protocoles basés sur les signatures qui nécessitent la participation d’un grand nombre d’utilisateurs, tels que les coinjoins ou les conceptions précédentes d’usines : si 1 000 utilisateurs acceptent de participer au protocole mais que l’un d’entre eux devient indisponible pendant la signature, les 999 autres signatures sont inutiles. Si, lors de la prochaine tentative, un autre utilisateur individuel devient indisponible, les 998 autres signatures collectées lors de la deuxième tentative sont inutiles. Il propose les covenants tels que OP_CHECKTEMPLATEVERIFY et SIGHASH_ANYPREVOUT comme solution à ce problème : ils permettent à une seule petite transaction de restreindre ses fonds à être dépensés uniquement dans une ou plusieurs transactions enfants prédéfinies ultérieures. Les transactions ultérieures peuvent également être limitées par un covenant.
  
  Law utilise ce mécanisme pour créer un arbre de temporisation où une transaction de financement paie un arbre de transactions enfants prédéfinies qui sont finalement dépensées hors chaîne dans un grand nombre de canaux de paiement séparés. Un mécanisme similaire à celui utilisé par Ark (voir le Bulletin #253) permet à chacun des canaux de paiement d’être éventuellement mis sur la chaîne, mais il permet également au financeur de l’usine de récupérer les fonds de tout canal qui n’a pas été mis onchain après expiration. Cela peut être extrêmement efficace : un arbre de temporisation hors chaîne finançant des millions de canaux peut être créé à l’aide d’une seule petite transaction onchain. Après expiration, les fonds peuvent être récupérés par le financeur de l’usine dans une autre petite transaction onchain, les utilisateurs individuels retirant leurs fonds via LN vers leurs autres canaux avant la date d’expiration de l’usine.
  
  Le modèle ci-dessus est compatible avec la construction de canaux LN-Penalty actuellement utilisée ainsi qu’avec le mécanisme proposé LN-Symmetry. Cependant, le reste de l’article de Law examine une proposition de modification de son protocole Fully Factory Optimized Watchtower Free (FFO-WF) qui offre plusieurs avantages pour la conception d’une usine basée sur les covenants. En plus des avantages décrits dans les bulletins précédents, tels que la nécessité uniquement d’utilisateurs occasionnels pour aller en ligne pendant quelques minutes tous les quelques mois et permettre aux utilisateurs dédiés d’utiliser leur capital à travers différents canaux de manière plus efficace, un nouvel avantage de la construction mise à jour permet au financeur de l’usine de déplacer des fonds pour les utilisateurs occasionnels d’une usine (basée sur une transaction onchain particulière) vers une autre usine (ancrée dans une transaction onchain différente) sans nécessiter d’interaction de l’utilisateur. Cela signifie que l’utilisateur occasionnel Alice, qui sait qu’elle doit se connecter avant l’expiration de 6 mois d’une usine, peut se connecter au mois 5 pour découvrir que ses fonds ont déjà été transférés vers une nouvelle usine avec plusieurs mois supplémentaires avant l’expiration. Alice n’a rien à faire ; elle conserve un contrôle complet et sans confiance de ses fonds. Cela réduit la possibilité qu’Alice se connecte très près de l’expiration, découvre que le financeur de l’usine est temporairement indisponible et soit obligée de mettre sa part de l’arbre de temporisation onchain, ce qui entraîne des frais de transaction et réduit la scalabilité globale du réseau.
  
  Anthony Towns a répondu avec une préoccupation qu’il a appelée le problème du “troupeau tonitruant” (appelé “spam d’expiration forcée” dans le document LN original) où l’échec délibéré ou accidentel d’un grand utilisateur dédié nécessite à de nombreux autres utilisateurs de mettre de nombreuses transactions sensibles au temps onchain en même temps. Par exemple, une usine avec un million d’utilisateurs peut nécessiter une confirmation sensible au temps jusqu’à un million de transactions plus une confirmation non sensible au temps jusqu’à deux millions de transactions supplémentaires pour que ces utilisateurs replacent ces fonds dans de nouveaux canaux. Il faut actuellement environ une semaine au réseau pour confirmer trois millions de transactions, donc les utilisateurs d’une usine d’un million d’utilisateurs peuvent souhaiter qu’une usine renouvelle leurs fonds quelques semaines avant l’expiration, ou peut-être plusieurs mois à l’avance s’ils sont préoccupés par le fait que plusieurs usines de plusieurs millions d’utilisateurs rencontrent des problèmes simultanément.
  
  Une version du document LN original suggérait que ce problème pourrait être résolu en utilisant une idée de Gregory Maxwell qui retarderait l’expiration lorsque “les blocs sont pleins” (par exemple, les frais sont supérieurs au montant normal). Dans sa réponse à Towns, Law a noté qu’il travaille sur une conception spécifique pour une solution de ce type qu’il publiera une fois qu’il aura fini d’y réfléchir.

Questions et réponses sélectionnées de Bitcoin Stack Exchange

Bitcoin Stack Exchange est l’un des premiers endroits où les contributeurs d’Optech cherchent des réponses à leurs questions, ou lorsque nous avons quelques moments libres pour aider les utilisateurs curieux ou confus. Dans cette rubrique mensuelle, nous mettons en évidence certaines des questions et réponses les plus votées publiées depuis notre dernière mise à jour.

• Comment fonctionnait la découverte des pairs dans Bitcoin v0.1 ? Pieter Wuille décrit l’évolution des mécanismes de découverte des pairs dans Bitcoin Core, depuis la recherche de pairs basée sur IRC dans la version 0.1 jusqu’aux adresses IP codées en dur et au semis de pairs DNS actuellement utilisés.
• Est-ce qu’une série de réorganisations pourrait causer la rupture de Bitcoin en raison de la restriction de différence de temps de bloc de 2 heures ? L’utilisateur fiatjaf demande si une série de réorganisations de la chaîne de blocs, potentiellement le résultat du tir ciblé de frais, pourrait causer des problèmes avec les restrictions de temps de bloc de Bitcoin. Antoine Poinsot et Pieter Wuille décrivent les deux restrictions de temps de bloc (doivent être supérieures au temps médian passé (MTP) et ne pas dépasser deux heures dans le futur selon l’heure locale du nœud) et concluent que les conditions des deux restrictions ne sont pas exacerbées par une réorg.
• Existe-t-il un moyen de télécharger les blocs à partir de zéro sans télécharger d’abord les en-têtes de bloc ? Pieter Wuille confirme qu’il est possible de télécharger les blocs sans les en-têtes, mais souligne que le désavantage est que le nœud ne saurait pas s’il est sur la meilleure chaîne avant d’avoir téléchargé et traité tous les blocs. Il compare cette approche avec la synchronisation des en-têtes en premier et décrit les messages P2P échangés pour chaque approche.
• Où est indiqué le plafond dur de 21 millions de bitcoins dans le code source de Bitcoin ? Pieter Wuille explique la fonction GetBlockSubsidy de Bitcoin Core qui définit le calendrier d’émission des subventions. Il renvoie également à une discussion précédente sur Stack Exchange concernant la limite de 20 999 999,9769 BTC de Bitcoin et pointe vers la constante MAX_MONEY qui est utilisée comme vérification de cohérence dans le code de validation du consensus.
• Les blocs contenant des transactions non standard sont-ils relayés à travers le réseau ou non, comme c’est le cas pour les transactions non standard ? L’utilisateur fiatjaf répond que bien que les transactions non standard selon la politique ne soient pas relayées par défaut sur le réseau P2P, les blocs contenant des transactions non standard sont toujours relayés, à condition que le bloc respecte les règles de consensus.
• Quand Bitcoin Core vous permet-il d’“abandonner une transaction” ? Murch détaille les trois conditions requises pour pouvoir abandonner une transaction dans Bitcoin Core :
  • la transaction n’a pas été abandonnée précédemment
  • ni la transaction ni une transaction en conflit ne sont confirmées
  • la transaction n’est pas dans le mempool du nœud

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.

• LND v0.17.0-beta.rc5 est un candidat aux versions pour la prochaine version majeure de cette implémentation populaire de nœud LN. Une nouvelle fonctionnalité expérimentale majeure prévue pour cette version, qui pourrait bénéficier de tests, est la prise en charge des “canaux taproot simples”.

Modifications de code et de documentation notables

Modifications notables cette semaine dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware WalletInterface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs) Lightning BOLTs, et Bitcoin Inquisition.

• Bitcoin Core #28492 met à jour le RPC descriptorprocesspsbt pour inclure la transaction sérialisée complète si le traitement du PSBT aboutit à une transaction diffusable. Voir le bulletin de la semaine dernière pour un PR fusionné similaire.
• Bitcoin Core GUI #119 met à jour la liste des transactions dans l’interface graphique pour ne plus fournir de catégorie spéciale pour “paiement à vous-même”. Maintenant, les transactions qui ont à la fois des entrées et des sorties qui affectent le portefeuille sont affichées sur des lignes séparées pour les dépenses et les réceptions. Cela peut améliorer la clarté pour les coinjoins et les payjoins, bien que Bitcoin Core ne supporte actuellement aucun de ces types de transactions par lui-même.
• Bitcoin Core GUI #738 ajoute une option de menu permettant de migrer un portefeuille hérité basé sur des clés et des types de script de sortie implicites stockés dans BerkeleyDB (BDB) vers un portefeuille moderne qui utilise des descripteurs stockés dans SQLite.
• Bitcoin Core #28246 met à jour la façon dont le portefeuille Bitcoin Core détermine internement quel script de sortie (scriptPubKey) une transaction doit payer. Auparavant, les transactions payaient simplement le script de sortie spécifié par l’utilisateur, mais si le support des paiements silencieux est ajouté à Bitcoin Core, le script de sortie devra être dérivé en fonction des données des entrées sélectionnées pour la transaction. Cette mise à jour rend cela beaucoup plus simple.
• Core Lightning #6311 supprime l’option de construction --developer qui produisait des binaires avec des options supplémentaires par rapport aux binaires CLN standard. Maintenant, les fonctionnalités expérimentales et non par défaut peuvent être accessibles en démarrant lightningd avec l’option de configuration d’exécution --developer. Une option de construction --enable-debug produira toujours un binaire légèrement différent avec certaines modifications bénéfiques pour les tests.
• Core Lightning #6617 met à jour le RPC showrunes pour fournir un nouveau champ de résultats, last_used, qui affiche la dernière fois que le rune (jeton d’authentification) a été utilisé.
• Core Lightning #6686 ajoute des en-têtes de stratégie de sécurité du contenu (CSP) et de partage des ressources entre origines (CORS) configurables pour l’interface REST de l’API de CLN.
• Eclair #2613 permet à Eclair de gérer toutes ses propres clés privées et d’utiliser Bitcoin Core avec seulement un portefeuille en mode surveillance (un portefeuille avec des clés publiques mais sans clés privées). Cela peut être particulièrement utile si Eclair est exécuté dans un environnement plus sécurisé que Bitcoin Core. Pour plus de détails, consultez la documentation ajoutée dans cette PR.
• LND #7994 ajoute la prise en charge de l’interface RPC du signataire distant pour l’ouverture de canaux taproot, ce qui nécessite de spécifier une clé publique et le nonce en deux parties MuSig2.
• LDK #2547 met à jour le code de recherche de chemin probabiliste en supposant qu’il est plus probable que les canaux distants aient la plupart de leur liquidité poussée d’un côté du canal. Par exemple, dans un canal distant de 1,00 BTC entre Alice et Bob, l’état le moins probable du canal est que Alice et Bob aient chacun 0,50 BTC. Il est plus probable que l’un d’entre eux ait 0,90 BTC—et encore plus probable que l’un d’entre eux ait 0,99 BTC.
• LDK #2534 ajoute la méthode ChannelManager::send_preflight_probes pour sonder les chemins de paiement avant d’essayer d’envoyer un paiement. Une sonde est générée par un expéditeur comme un paiement LN régulier, mais la valeur de son préimage HTLC est définie sur une valeur inutilisable (par exemple, une valeur connue uniquement de l’expéditeur); lorsqu’elle atteint sa destination, le destinataire ne connaît pas le préimage et le rejette, renvoyant une erreur. Si cette erreur est reçue, le sondeur sait que le chemin de paiement avait suffisamment de liquidité pour prendre en charge le paiement lorsqu’il a été envoyé, et qu’un paiement réel envoyé le long du même chemin pour le même montant réussira probablement. Si une autre erreur est reçue, telle qu’une erreur indiquant que l’un des sauts le long du chemin ne pouvait pas transmettre le paiement, un nouveau chemin peut être sondé avant d’envoyer le paiement réel.
  
  La sonde préalable au paiement (“prévol”) peut être utile avec de petites sommes d’argent pour trouver des sauts qui rencontrent des problèmes pouvant causer des retards. Si quelques centaines de sats (ou moins) restent bloqués pendant quelques heures, ce n’est pas grave pour la plupart des dépensiers—mais si le montant total d’un paiement représentant une partie importante du capital d’un nœud reste bloqué, cela peut être très ennuyeux. Il est également possible de sonder plusieurs chemins simultanément et d’utiliser les résultats pour choisir le meilleur chemin quelques instants plus tard lors de l’envoi d’un paiement.