Le bulletin de cette semaine mentionne brièvement une récente divulgation de sécurité affectant les utilisateurs de LN, décrit un article sur la réalisation de paiements conditionnels au résultat de l’exécution de programmes arbitraires, et annonce une proposition de BIP visant à ajouter des champs aux PSBT pour MuSig2. Sont également incluses nos sections régulières avec des annonces de mises à jour et versions candidates, ainsi que les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

  • ● Divulgation de sécurité concernant LN : Antoine Riard a publié sur les listes de diffusion Bitcoin-Dev et Lightning-Dev la divulgation complète d’un problème qu’il avait précédemment signalé de manière responsable aux développeurs travaillant sur le protocole Bitcoin et diverses implémentations LN populaires. Les versions les plus récentes de Core Lightning, Eclair, LDK et LND contiennent toutes des mesures d’atténuation qui rendent l’attaque moins pratique, bien qu’elles n’éliminent pas le problème sous-jacent.

    La divulgation a été faite après la date limite habituelle des actualités d’Optech, nous ne pouvons donc fournir que le lien ci-dessus dans la newsletter de cette semaine. Nous fournirons un résumé régulier dans la newsletter de la semaine prochaine.

  • ● Paiements conditionnels à une computation arbitraire : Robin Linus a publié sur la liste de diffusion Bitcoin-Dev un article qu’il a écrit sur BitVM, une combinaison de méthodes qui permet de payer des bitcoins à quelqu’un qui prouve avec succès qu’un programme arbitraire s’est exécuté correctement. Cette méthode est applicable sur Bitcoin dès aujourd’hui car aucun changement de consensus n’est requis.

    Pour fournir un contexte, une caractéristique bien connue de Bitcoin est d’exiger que quelqu’un satisfasse une expression de programmation (appelée script) afin de dépenser des bitcoins associés à ce script. Par exemple, un script qui ne peut être exécuté que si la clé privée correspondant à la clé publique qu’il contient crée une signature s’engageant à une transaction de dépense. Les scripts doivent être écrits dans le langage de Bitcoin (appelé Script) pour être appliqués par consensus, mais Script est délibérément limité dans sa flexibilité.

    L’article de Linus contourne certaines de ces limites. Si Alice compte sur Bob pour agir si un programme est exécuté de manière incorrecte, mais ne veut pas lui faire confiance pour autre chose, elle peut payer des fonds à un taproot qui permettra à Bob de réclamer les fonds s’il démontre qu’Alice n’a pas exécuté correctement un programme arbitraire. Si Alice exécute correctement le programme, elle peut dépenser les fonds même si Bob tente de l’en empêcher.

    Pour utiliser un programme arbitraire, il doit être décomposé en une primitive très basique (une porte NAND) et un engagement doit être fait pour chaque porte. Cela nécessite l’échange hors chaîne d’une très grande quantité de données, potentiellement plusieurs gigaoctets même pour un programme arbitraire assez basique, mais Alice et Bob n’ont besoin que d’une seule transaction sur chaîne dans le cas où Bob reconnaît qu’Alice a exécuté correctement le programme. Dans le cas où Bob n’est pas d’accord, il devrait être en mesure de démontrer l’échec d’Alice dans un nombre relativement restreint de transactions onchain. Si la configuration a été effectuée dans un canal de paiement entre Alice et Bob, plusieurs programmes peuvent être exécutés à la fois en parallèle et en séquence sans aucune trace onchain, à l’exception de la configuration du canal et d’une fermeture mutuelle ou forcée où Bob tente de démontrer qu’Alice n’a pas suivi correctement la logique du programme arbitraire.

    BitVM peut être appliqué de manière fiable dans des cas où Alice et Bob sont des adversaires naturels, par exemple lorsqu’ils paient des fonds à une sortie qui sera payée à celui d’entre eux qui gagne à un jeu d’échecs. Ils peuvent ensuite utiliser deux programmes arbitraires (presque identiques), chacun prenant le même ensemble arbitraire de coups d’échecs. Un programme renverra “vrai” si Alice a gagné et l’autre renverra “vrai” si Bob a gagné. Une partie publiera ensuite onchain la transaction qui affirme que son programme s’évalue à vrai (qu’elle a gagné) ; l’autre partie acceptera cette affirmation (reconnaissant la perte des fonds) ou démontrera la fraude (recevant les fonds en cas de succès). Dans les cas où Alice et Bob ne seraient pas naturellement des adversaires, Alice peut être en mesure de l’inciter à vérifier le calcul correct, par exemple en lui offrant ses fonds si Bob peut prouver qu’elle n’est pas parvenue à calculer correctement.

    L’idée a fait l’objet d’un nombre important de discussions sur la liste de diffusion ainsi que sur Twitter et divers podcasts axés sur Bitcoin. Nous prévoyons des discussions continues dans les semaines et les mois à venir.

  • ● Proposition de BIP pour les champs MuSig2 dans les PSBT : Andrew Chow a posté sur la liste de diffusion Bitcoin-Dev avec un projet de BIP, en partie basé sur un travail antérieur de Sanket Kanjalkar, pour ajouter plusieurs champs à toutes les versions des PSBT pour les “clés, les nonces publics et les signatures partielles produites avec MuSig2”.

    Anthony Towns a demandé si le BIP proposé inclurait également des champs pour les signatures adaptatives, mais les discussions ultérieures ont indiqué que cela devrait probablement être défini dans un BIP séparé.

Modifications apportées aux services et aux logiciels clients

Dans cette rubrique mensuelle, nous mettons en évidence les mises à jour intéressantes des portefeuilles et services Bitcoin.

  • ● Sortie de la bibliothèque Python BIP-329 : La bibliothèque Python BIP-329 est un ensemble d’outils qui peuvent lire, écrire, chiffrer et déchiffrer des fichiers d’étiquettes de portefeuille conformes à BIP329.

  • ● Annonce de l’outil de test LN Doppler : Récemment annoncé, Doppler prend en charge la définition de topologies de nœuds Bitcoin et Lightning et l’activité de paiement onchain/offchain à l’aide d’un langage spécifique au domaine (DSL) pour tester les implémentations LND, CLN et Eclair ensemble.

  • ● Sortie de Coldcard Mk4 v5.2.0 : Les mises à jour du firmware incluent le support de BIP370 pour la version 2 PSBTs, support supplémentaire BIP39 et capacités de plusieurs semences.

  • ● Circuits Tapleaf : une démo de BitVM : Circuits Tapleaf est une implémentation de concept de preuve de circuits Bristol utilisant l’approche BitVM décrite précédemment dans le bulletin.

  • ● Samourai Wallet 0.99.98i publié : La version 0.99.98i inclut des fonctionnalités supplémentaires de PSBT, d’étiquetage des UTXO et d’envoi en lot.

  • ● Krux : firmware de dispositif de signature : Krux est un projet de firmware open-source pour construire des dispositifs de signature matériels en utilisant du matériel courant.

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.

Changements notables dans le code et la documentation

Changements notables cette semaine dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Interface de Portefeuille Matériel (HWI), Rust Bitcoin, Serveur BTCPay , BDK, Propositions d’Amélioration Bitcoin (BIPs), Lightning BOLTs, et Inquisition Bitcoin.

  • ● Bitcoin Core #27255 porte miniscript vers tapscript. Ce changement de code rend miniscript une option pour les descripteurs de sortie P2TR, ajoutant la prise en charge à la fois de la surveillance et de la signature des “descripteurs TapMiniscript”. Auparavant, miniscript était disponible uniquement pour les descripteurs de sortie P2WSH. L’auteur note qu’un nouveau fragment multi_a est introduit exclusivement pour les descripteurs P2TR qui correspond à la sémantique de multi dans les descripteurs P2WSH. La discussion sur le PR note qu’une grande partie du travail a été consacrée au suivi approprié des limites de ressources modifiées pour tapscript.

  • ● Eclair #2703 décourage les utilisateurs qui font une dépense de faire transiter les paiements par le nœud local lorsque le solde du nœud est faible et qu’il serait probablement nécessaire de rejeter ces paiements. Cela est réalisé en annonçant que le montant HTLC maximum du nœud a été réduit. Éviter les paiements rejetés améliore l’expérience lors d’une dépense et aide à éviter que le nœud local ne soit pénalisé par les systèmes de recherche de chemin qui rabaissent les nœuds qui n’ont pas réussi à faire transiter un paiement récemment.

  • ● LND #7267 rend possible la création de routes vers des chemins aveugles, rapprochant ainsi LND d’une prise en charge complète des paiements aveugles.

  • ● BDK #1041 ajoute un module pour obtenir des données sur la chaîne de blocs à partir de Bitcoin Core en utilisant l’interface RPC de ce programme.