Le bulletin de cette semaine résume un nouveau schéma pour les jetons d’utilisation anonymes qui pourraient être utilisés pour les annonces de canaux LN et plusieurs autres protocoles de coordination résistants aux attaques Sybil, inclut des liens vers des discussions sur un nouveau schéma de division de phrase de semence BIP39, annonce une alternative à BitVM pour vérifier l’exécution réussie de programmes arbitraires dans des protocoles de contrat interactifs, et rapporte des suggestions pour la mise à jour du processus BIP.

Actualités

• ● Jetons d’utilisation anonymes : Adam Gibson a publié sur Delving Bitcoin un schéma qu’il a développé permettant à quiconque pouvant dépenser par chemin de clé un UTXO de prouver qu’il pourrait le dépenser sans révéler quel UTXO il s’agit. Cela fait suite aux travaux précédents de Gibson sur le développement de mécanismes anti-Sybil PoDLE (utilisé dans l’implémentation coinjoin de Joinmarket) et RIDDLE.

  Une utilisation qu’il décrit est l’annonce de canaux LN. Chaque nœud LN annonce ses canaux aux autres nœuds LN afin qu’ils puissent trouver des chemins pour acheminer les fonds à travers le réseau. Une grande partie de ces informations sur les canaux est stockée en mémoire et les annonces sont souvent rediffusées pour s’assurer qu’elles atteignent autant de nœuds que possible. Si un attaquant pouvait annoncer facilement de faux canaux, il pourrait gaspiller une quantité excessive de mémoire et de bande passante des nœuds honnêtes, en plus de perturber la recherche de chemin. Les nœuds LN traitent cela aujourd’hui en acceptant uniquement les annonces qui sont signées par une clé appartenant à un UTXO valide. Cela nécessite que les co-propriétaires du canal identifient l’UTXO spécifique qu’ils co-détiennent, ce qui peut associer ces fonds à d’autres transactions en chaîne passées ou futures qu’ils créent (ou conduire à une association inexacte).

  Avec le schéma de Gibson, appelé jetons d’utilisation anonymes avec arbres courbes (autct), les co-propriétaires du canal pourraient signer un message sans révéler leur UTXO. Un attaquant sans UTXO ne pourrait pas créer de signature valide. Un attaquant qui possède un UTXO pourrait créer une signature valide, mais il devrait conserver autant d’argent dans cet UTXO qu’un nœud LN devrait conserver dans un canal, limitant ainsi le pire cas de toute attaque. Voir le Bulletin #261 pour une discussion précédente sur la dissociation des annonces de canal d’UTXOs particuliers.

  Gibson décrit également plusieurs autres façons d’utiliser les autct. Un mécanisme de base pour accomplir ce type de confidentialité, les signatures en anneau, est connu depuis longtemps, mais Gibson utilise une nouvelle construction cryptographique (arbres courbes) pour rendre les preuves plus compactes et plus rapides à vérifier. Il fait également en sorte que chaque preuve s’engage privément sur la clé utilisée afin qu’un seul UTXO ne puisse pas être utilisé pour créer un nombre illimité de signatures valides.

  En plus de publier le code, Gibson a également publié un preuve de concept sur le forum qui nécessite de fournir une preuve automatique pour s’inscrire, offrant un environnement où chacun est reconnu comme détenteur de bitcoins mais sans avoir à fournir d’informations d’identification sur eux-mêmes ou leurs bitcoins.

• ● Fractionnement de phrase de semence BIP39 : Rama Gan a posté sur la liste de diffusion Bitcoin-Dev un lien vers un ensemble d’outils qu’ils ont développé pour générer et fractionner une phrase de semence BIP39 sans utiliser d’équipement informatique électronique (sauf pour imprimer les instructions et les modèles). Cela est similaire à codex32 mais fonctionne sur des mots de semence BIP39 qui sont compatibles avec presque tous les dispositifs de signature matérielle actuels et de nombreux portefeuilles logiciels.

  Andrew Poelstra, co-auteur de codex32, a répondu avec plusieurs commentaires et suggestions. Sans essayer les deux schémas—ce qui prendrait plusieurs heures pour chacun—l’ensemble exact des compromis n’est pas clair. Cependant, les deux semblent offrir les mêmes capacités fondamentales : des instructions pour générer une seed de manière sécurisée hors ligne ; la capacité de diviser la seed en plusieurs parts en utilisant le partage secret de Shamir; la capacité de reconstituer les parts en la seed originale; et la capacité de vérifier les sommes de contrôle sur les parts et la seed originale, permettant aux utilisateurs de détecter la corruption des données tôt lorsque les données originales pourraient encore être récupérables.

• ● Alternative à BitVM : Sergio Demian Lerner et plusieurs co-auteurs ont posté sur la liste de diffusion Bitcoin-Dev à propos d’une nouvelle architecture de CPU virtuel basée en partie sur les idées derrière BitVM. Le but de leur projet, BitVMX, est de pouvoir prouver efficacement l’exécution correcte de tout programme qui peut être compilé pour fonctionner sur une architecture CPU établie, telle que RISC-V. Comme BitVM, BitVMX ne nécessite aucun changement de consensus, mais il nécessite qu’une ou plusieurs parties désignées agissent en tant que vérificateur de confiance. Cela signifie que plusieurs utilisateurs participant de manière interactive à un protocole de contrat peuvent empêcher une ou plusieurs des parties de retirer de l’argent du contrat à moins que cette partie n’exécute avec succès un programme arbitraire spécifié par le contrat.

  Lerner renvoie à un document sur BitVMX qui le compare à BitVM original (voir le Bulletin #273) et aux détails limités disponibles sur les projets de suivi des développeurs de BitVM original. Un site web accompagnateur fournit des informations supplémentaires sous une forme légèrement moins technique.

• ● Discussion continue sur la mise à jour de BIP2 : Mark “Murch” Erhardt a continué la discussion sur la liste de diffusion Bitcoin-Dev concernant la mise à jour de BIP2, qui est le document qui décrit actuellement le processus des propositions d’amélioration de Bitcoin (BIP). Son email décrit plusieurs problèmes, suggère des solutions pour beaucoup d’entre eux, et sollicite des retours sur ses suggestions ainsi que des propositions de solutions pour les problèmes restants. Pour les discussions précédentes sur la mise à jour de BIP2, voir le Bulletin #297.

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.18.0-beta.rc2 est un candidat à la version pour la prochaine version majeure de cette implémentation populaire de nœud LN.

Changements notables dans le code et la documentation

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

• ● Core Lightning #7190 ajoute un décalage supplémentaire (appelé chainlag) dans le calcul du timelock HTLC. Cela permet aux HTLCs de cibler la hauteur actuelle du bloc au lieu du bloc le plus récent que le nœud LN a traité (sa hauteur de synchronisation). Cela rend sûr pour un nœud d’envoyer des paiements pendant le processus de synchronisation de la blockchain.

• ● LDK #2973 implémente le support pour OnionMessenger afin d’intercepter les messages en onion au nom des pairs hors ligne. Il génère des événements lors de l’interception de messages et lorsque le pair revient en ligne pour la transmission. Les utilisateurs doivent maintenir une liste d’autorisation pour stocker uniquement les messages pour les pairs pertinents. C’est un pas vers le support des paiements asynchrones à travers held_htlc_available de BOLTs #989. Dans ce protocole, Alice veut payer Carol à travers Bob, mais Alice ne sait pas si Carol est en ligne. Alice envoie un message onion à Bob ; Bob retient le message jusqu’à ce que Carol soit en ligne ; Carol ouvre le message, qui lui dit de demander un paiement à Alice (ou au fournisseur de services Lightning d’Alice) ; Carol demande le paiement et Alice l’envoie de manière normale.

• ● LDK #2907 étend la gestion de OnionMessage pour accepter une entrée Responder optionnelle et retourner un objet ResponseInstructions qui indique comment la réponse au message doit être gérée. Ce changement permet des réponses de messagerie onion asynchrones et ouvre la porte à des mécanismes de réponse plus complexes, tels que ceux qui pourraient être nécessaires pour les paiements asynchrones.

• ● BDK #1403 met à jour le crate bdk_electrum pour utiliser de nouvelles structures de synchronisation/scan complet introduites dans BDK #1413, une liste chaînée CheckPoint consultable avec BDK #1369, et des transactions clonables à faible coût dans des pointeurs Arc du BDK #1373. Ce changement améliore la performance de portefeuilles scannant les données de transaction via un serveur de style Electrum. Il est désormais également possible de récupérer des TxOuts pour permettre le calcul des frais sur les transactions reçues d’un portefeuille externe.

• ● BIPs #1458 ajoute BIP352 qui propose des paiements silencieux, un protocole pour des adresses de paiement réutilisables qui génèrent une adresse unique sur la chaîne à chaque utilisation. Le projet de BIP a été discuté pour la première fois dans le Bulletin #255.