Le bulletin de cette semaine décrit un protocole de génération de clés distribué pour le schéma de signature limitée sans script FROST et renvoie à une introduction complète à la linéarisation de clusters. Nous incluons également nos sections régulières décrivant les mises à jour des clients et des services, les nouvelles versions et les versions candidates, ainsi que les changements apportés aux principaux logiciels d’infrastructure Bitcoin.

Nouvelles

• ● Protocole de génération de clés distribué pour FROST : Tim Ruffing et Jonas Nick ont publié sur la liste de diffusion Bitcoin-Dev un brouillon de BIP avec une référence d’implémentation de ChillDKG, un protocole pour générer de manière sécurisée des clés à utiliser avec les signatures limitées sans script de style FROST compatibles avec les signatures schnorr de Bitcoin.

  Les signatures limitées sans script sont compatibles avec la création de n clés, dont n’importe quelles t peuvent être utilisées coopérativement pour créer une signature valide. Par exemple, un schéma 2-sur-3 crée trois clés, dont deux quelconques peuvent produire une signature valide. Étant sans script, le schéma repose entièrement sur des opérations externes au consensus et à la blockchain, contrairement aux opérations de signature limitée scriptées intégrées de Bitcoin (par exemple, en utilisant OP_CHECKMULTISIG).

  De manière similaire à la génération d’une clé privée Bitcoin régulière, chaque personne créant une clé pour les signatures limitées sans script doit générer un nombre grand et aléatoire sans divulguer ce nombre à quiconque d’autre. Cependant, chaque personne doit également distribuer des parts dérivées de ce nombre aux autres utilisateurs afin qu’un nombre limité d’entre eux puisse créer une signature si cette clé est indisponible. Chaque utilisateur doit vérifier que les informations qu’il a reçues de chaque autre utilisateur ont été générées correctement. Plusieurs protocoles de génération de clés pour effectuer ces étapes existent, mais ils supposent que les utilisateurs générant les clés ont accès à un canal de communication qui est chiffré et authentifié entre des paires individuelles d’utilisateurs et qui permet également une diffusion authentifiée et incensurable de chaque utilisateur vers tous les autres utilisateurs. Le protocole ChillDKG combine un algorithme de génération de clés bien connu pour FROST avec des primitives cryptographiques modernes supplémentaires et des algorithmes simples pour fournir la communication sécurisée, authentifiée et prouvée incensurable nécessaire.

  Le chiffrement et l’authentification entre les participants commencent par un échange elliptic curve diffie-hellman (ECDH). La preuve de non-censure est créée par chaque participant en utilisant sa clé de base pour signer un transcript de la session depuis son début jusqu’à la production de la clé publique limitée sans script (qui est la fin de la session). Avant d’accepter la clé publique limitée comme correcte, chaque participant vérifie le transcript de session signé de chaque autre participant.

  L’objectif est de fournir un protocole entièrement généralisé qui est utilisable dans tous les cas où les gens veulent générer des clés pour des signatures limitées sans script basées sur FROST. De plus, le protocole aide à simplifier les sauvegardes : tout ce dont un utilisateur a besoin est sa graine privée et certaines données de récupération qui ne sont pas sensibles à la sécurité (mais qui ont des implications sur la vie privée). Dans un message de suivi, Jonas Nick a mentionné qu’ils envisagent d’étendre le protocole pour chiffrer les données de récupération avec une clé dérivée de la graine, de sorte que la seule donnée que l’utilisateur doit garder privée soit sa graine.

• ● Introduction à la linéarisation des clusters : Pieter Wuille a publié sur Delving Bitcoin une description détaillée de toutes les parties principales de la linéarisation des clusters, la base pour un mempool en cluster. Les précédents bulletins d’Optech ont tenté d’introduire le sujet à mesure que ses concepts clés étaient développés et publiés, mais cette vue d’ensemble est beaucoup plus complète. Elle guide les lecteurs dans un ordre des concepts fondamentaux aux algorithmes spécifiques mis en œuvre. Elle se termine par des liens vers plusieurs pull requests de Bitcoin Core qui implémentent des parties du mempool en cluster.

Modifications apportées aux services et aux logiciels clients

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

• ● ZEUS ajoute les offres BOLT12 et le support BIP353 : La version v0.8.5 tire parti du service TwelveCash pour prendre en charge les offres et BIP353 (voir Newsletter #307).

• ● Phoenix ajoute les offres BOLT12 et le support BIP353 : La version Phoenix 2.3.1 a ajouté le support des offres et Phoenix 2.3.3 a ajouté le support BIP353.

• ● Stack Wallet ajoute le support RBF et CPFP : La version v2.1.1 de Stack Wallet a ajouté le support pour l’augmentation des frais via RBF et CPFP ainsi que le support Tor.

• ● BlueWallet ajoute le support de l’envoi de paiements silencieux : Dans la version v6.6.7, BlueWallet a ajouté la capacité d’envoyer à des adresses de paiements silencieux.

• ● Annonce de BOLT12 Playground : Strike a annoncé un environnement de test pour les offres BOLT12. Le projet utilise Docker pour initier et automatiser les portefeuilles, les canaux et les paiements à travers différentes implémentations de LN.

• ● Annonce du dépôt de test Moosig : Ledger a publié un dépôt de test basé sur Python pour utiliser MuSig2 et BIP388 les politiques de portefeuille pour les portefeuilles descripteurs.

• ● Outil de visualisation en temps réel de Stratum publié : Le site web stratum.work, basé sur des recherches précédentes, affiche en temps réel les messages Stratum d’une variété de pools de minage Bitcoin. avec le code source disponible.

• ● BMM 100 Mini Miner annoncé : Le matériel de minage de Braiins est livré avec un sous-ensemble de fonctionnalités Stratum V2 activées par défaut.

• ● Coldcard publie une spécification de diffusion de transaction basée sur URL : Le protocole permet la diffusion d’une transaction Bitcoin en utilisant une requête HTTP GET et peut être utilisé par des dispositifs de signature matérielle basés sur NFC, parmi d’autres cas d’utilisation.

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, BTCPay Server, BDK, Propositions d’Amélioration de Bitcoin (BIPs), Lightning BOLTs, Lightning BLIPs, Inquisition Bitcoin, et BINANAs.

• ● Bitcoin Core #26596 utilise la nouvelle base de données en lecture seule pour migrer les portefeuilles hérités vers des portefeuilles descriptor. Ce changement ne déprécie pas les portefeuilles hérités ou le BerkeleyDatabase hérité. Une nouvelle classe LegacyDataSPKM a été créée contenant uniquement les données essentielles et les fonctions nécessaires pour charger un portefeuille hérité en vue de sa migration. Voir le Bulletin #305 pour une introduction à la BerkeleyRODatabase.

• ● Core Lightning #7455 améliore le traitement des messages onion par connectd en implémentant le transfert via short_channel_id (SCID) et node_id (voir le Bulletin #307 pour une discussion sur un changement similaire dans LDK). Les messages onion sont maintenant toujours activés, et les messages entrants sont limités à 4 par seconde.

• ● Eclair #2878 rend les fonctionnalités de masquage de route et de mise en veille des canaux optionnelles, puisqu’elles sont maintenant entièrement implémentées et font partie de la spécification BOLT (voir les Bulletins #245 et #309). Un nœud Eclair annonce le support de ces fonctionnalités à ses pairs, mais la fonction route_blinding est désactivée par défaut car il ne transférera pas les paiements aveuglés qui n’utilisent pas le trampoline routing.

• ● Rust Bitcoin #2646 introduit de nouveaux inspecteurs pour les structures de script et de témoin telles que redeem_script pour assurer la conformité avec les règles de BIP16; concernant les dépenses P2SH, taproot_control_block, et taproot_annex pour assurer la conformité avec les règles BIP341 ; et witness_script pour garantir que les scripts témoins P2WSH respectent les règles BIP141. Voir le Bulletin #309.

• ● BDK #1489 met à jour bdk_electrum pour utiliser des preuves de Merkle pour la vérification simplifiée des paiements (SPV). Il récupère les preuves de Merkle et les en-têtes de blocs en même temps que les transactions, valide que les transactions se trouvent dans des blocs confirmés avant d’insérer des ancres, et supprime la gestion des réorganisations de full_scan. La PR introduit également ConfirmationBlockTime comme un nouveau type d’ancre, remplaçant les types précédents.

• ● BIPs #1599 ajoute BIP46 pour un schéma de dérivation pour les portefeuilles HD qui créent des adresses verrouillées dans le temps utilisées pour les fidelity bonds comme celles utilisées pour le matching de marché coinjoin de style JoinMarket. Les fidelity bonds améliorent la résistance Sybil du protocole en créant un système de réputation où les créateurs prouvent leur sacrifice intentionnel de la valeur temporelle de l’argent en verrouillant dans le temps des bitcoins.

• ● BOLTs #1173 rend le champ channel_update optionnel dans les messages onion d’échec. Les nœuds ignorent maintenant ce champ en dehors du paiement actuel pour éviter le profilage des expéditeurs de HTLC. Le changement vise à décourager les retards de paiement dus à des paramètres de canal obsolètes tout en permettant encore aux nœuds avec des données de gossip périmées de bénéficier des mises à jour lorsque nécessaire.

• ● BLIPs #25 ajoute une description de comment BLIP25 permet le transfert de HTLCs qui sous-paient la valeur en onion encodée. Par exemple, Alice fournit une facture lightning à Bob mais elle n’a pas de canaux de paiement, donc quand Bob paie, Carol (le LSP d’Alice) crée un canal à la volée. Pour permettre à Carol de prendre des frais d’Alice pour couvrir le coût de la commission initiale onchain qui crée un canal JIT, ce protocole est utilisé, et Alice recoit un HTLC qui sous-paie la valeur en onion encodée. Pour une discussion précédente sur une mise en œuvre de cela dans LDK, voir le Bulletin #257.