Le bulletin de cette semaine décrit une proposition d’utilisation de covenants pour améliorer considérablement la scalabilité de LN. 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 demodification 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.

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.