Bitcoin Optech #156  : BIP, documents de normes, etc.

cs_srgbw_620//screen-shot-2021-07-07-at-72252-am les documents standard pour l’interopérabilité du protocole LN, et plus encore.

ainsi que des ressources qui les aident à en savoir plus nous republions le dernier numéro de cette newsletter ci-dessous

Le bulletin d’information de cette semaine décrit un ensemble de BIP pour les descripteurs de script de sortie, résume une proposition visant à créer un ensemble de documents de normes pour les extensions de protocole LN et l’interopérabilité des applications, et traite de la normalisation de la prise en charge des ouvertures de canaux zéro-conf pré-approuvés. Sont également inclus nos sections régulières décrivant comment se préparer pour la racine pivotante, les versions et les versions candidates, et les changements notables apportés aux projets d’infrastructure Bitcoin populaires.

Nouvelles

• BIP pour les descripteurs de script de sortie  : Andrew Chow a publié sur la liste de diffusion Bitcoin-Dev une proposition d’ensemble de BIP pour normaliser les descripteurs de script de sortie. Un noyau BIP fournit la sémantique générale et les éléments primaires utilisés par les descripteurs. Six BIP supplémentaires décrivent des fonctions d’expansion telles que pkh(), wpkh() et tr() qui utilisent leurs arguments pour remplir un modèle de script. Les multiples BIP permettent aux développeurs de choisir les fonctionnalités de descripteur qu’ils souhaitent implémenter, par ex. les portefeuilles plus récents peuvent ne jamais implémenter l’ancien descripteur pkh().

  Les descripteurs ont été initialement mis en œuvre pour Bitcoin Core et ont été adoptés de plus en plus au cours de la dernière année par d’autres projets. Ils sont sur le point de voir une augmentation significative de leur utilisation alors que les portefeuilles commencent à explorer la flexibilité permise par la racine pivotante et la possibilité de simplifier l’accès aux scripts flexibles grâce à des outils tels que miniscript

• BLIPs  : Ryan Gentry a publié sur la liste de diffusion Lightning-Dev une proposition pour une collection de propositions d’amélioration de Bitcoin Lightning (BLIP), des documents qui décrivent les extensions et les applications de LN qui bénéficieront des normes d’interopérabilité. René Pickhardt lié à une proposition presque identique qu’il avait faite en 2018.

  Au cours de la discussion, l’idée a semblé bénéficier d’un large soutien, bien que des inquiétudes aient été soulevées quant au fait qu’elle ne résout pas réellement l’obstacle à l’incorporation de ces normes dans les documents de base de BOLT – cet obstacle étant les développeurs expérimentés qui manquent de temps pour examiner les nombreuses propositions de la communauté. Si les BLIP sont fusionnés sans examen significatif, cela augmente le risque qu’ils contiennent des bogues ou qu’ils ne parviennent pas à obtenir un large soutien de la part de plusieurs parties prenantes, entraînant une fragmentation car différents projets adoptent des normes concurrentes. Pourtant, des protocoles non principaux sont déjà en cours de création et la plupart des participants à la discussion semblaient penser qu’il serait principalement bénéfique de fournir une archive bien connue où la documentation sur ces protocoles pourrait être publiée

• Ouverture du canal Zero-conf : Rusty Russell a lancé une discussion sur la liste de diffusion Lightning-Dev à propos de la standardisation de la gestion des canaux zero-conf, également connus sous le nom de canaux turbo. Il s’agit de nouveaux canaux à financement unique où le bailleur de fonds donne tout ou partie de ses fonds initiaux à l’accepteur. Ces fonds ne sont pas sécurisés jusqu’à ce que la transaction ouverte du canal reçoive un nombre suffisant de confirmations, il n’y a donc aucun risque que l’accepteur dépense une partie de ces fonds via le bailleur de fonds en utilisant le protocole LN standard.

  Par exemple, Alice a plusieurs BTC dans un compte à l’échange de garde de Bob. Alice demande à Bob d’ouvrir une nouvelle chaîne en lui payant 1,0 BTC. Parce que Bob se fait confiance pour ne pas dépenser deux fois le canal qu’il vient d’ouvrir, il peut autoriser Alice à envoyer 0,1 BTC via son nœud à la tierce Carol avant même que la transaction d’ouverture du canal n’ait reçu une seule confirmation

• Certaines implémentations de LN soutiennent déjà l’idée d’une manière non standardisée et tous les participants à la discussion semblaient être en faveur de sa standardisation. Les détails exacts à utiliser étaient encore en discussion au moment de la rédaction

Préparation de la racine pivotante #3  : descripteurs de la racine pivotante

Une série hebdomadaire sur la façon dont les développeurs et les fournisseurs de services peuvent se préparer à l’activation prochaine de la racine pivotante à la hauteur de bloc 709 632.

Les descripteurs de script de sortie fournissent aux portefeuilles un moyen générique de stocker les informations nécessaires à la création d’adresses, de rechercher efficacement les sorties payant ces adresses et de dépenser plus tard à partir de ces adresses. De plus, les descripteurs sont raisonnablement compacts et contiennent une somme de contrôle de base, ce qui les rend pratiques pour sauvegarder les informations d’adresse, les copier entre différents portefeuilles ou les partager entre des portefeuilles qui coopèrent pour fournir plusieurs signatures.

Bien que les descripteurs ne soient actuellement utilisés que par quelques projets, eux et le projet miniscript associé ont le potentiel d’améliorer considérablement l’interopérabilité entre les différents portefeuilles et outils. Cela deviendra de plus en plus important à mesure que de plus en plus d’utilisateurs profiteront des avantages de la racine pivotante pour améliorer leur sécurité grâce aux signatures multiples et leur résilience grâce aux conditions de dépenses de sauvegarde.

Avant que cela ne se produise, les descripteurs doivent être mis à jour pour fonctionner avec la racine pivotante. C’était le sujet de la demande de tirage Bitcoin Core #22051 récemment fusionnée. La syntaxe a été conçue pour permettre à un seul modèle de descripteur de fournir toutes les informations nécessaires pour utiliser à la fois les dépenses de chemin de clé P2TR et les dépenses de chemin de script. Pour un simple signature unique, le descripteur suivant est suffisant  :

tr()

La même syntaxe peut également être utilisée pour les signatures multiples et les signatures à seuil. Par exemple, Alice, Bob et Carol agrègent leurs clés à l’aide de MuSig, puis paient à tr().

De manière non intuitive, la clé spécifiée par tr() ne sera pas la clé encodée dans l’adresse. Le descripteur tr() suit une recommandation de sécurité de BIP341 pour utiliser une clé interne qui s’engage dans une arborescence de scripts inutile. Cela élimine une attaque contre les utilisateurs de schémas d’agrégation de clés naïfs (les schémas plus avancés tels que MuSig et MuSig2 ne sont pas affectés).

C}E} } spécifie l’arbre suivant  :

Par exemple, si Alice veut pouvoir dépenser via keypath, mais qu’elle veut également autoriser Bob, Carol, Dan et Edmond à dépenser via un scriptpath qui génère une piste d’audit pour elle (mais pas pour la surveillance de chaîne tierce), Alice peut utiliser le descripteur suivant  :

paquet()}paquet()} )

Les fonctionnalités ci-dessus sont tout ce qui est nécessaire pour utiliser des descripteurs pour la racine pivotante, mais PR #22051 note qu’il manque encore certaines choses qui pourraient être ajoutées pour rendre les descripteurs mieux décrivant complètement les politiques attendues  :

• Chemins de clé annulés  : certains utilisateurs peuvent vouloir empêcher l’utilisation des dépenses de chemin de clé afin de forcer les dépenses de chemin de script. Cela peut être fait maintenant en utilisant une clé non utilisable comme premier paramètre de tr(), mais ce serait bien de permettre aux portefeuilles de stocker cette préférence dans le descripteur lui-même et de lui faire calculer un chemin de clé non utilisable préservant la confidentialité

Pour permettre la vérification par lots dans la racine pivotante, le multisig basé sur un script est géré un peu différemment dans tapscript, donc les descripteurs tr() doivent actuellement spécifier tous les opcodes multisig nécessaires via un script raw(). Des versions mises à jour de multi() etsortedmulti() pour les tapscripts seraient bien d’avoir

nous avons décrit Alice, Bob et Carol agrégeant manuellement leurs clés afin d’utiliser un descripteur tr(). Idéalement, il y aurait une fonction qui leur permettrait de spécifier quelque chose comme tr(musig(. )) afin qu’ils puissent conserver toutes les informations clés d’origine et les utiliser pour remplir les champs des PSBT qu’ils utilisent pour coordonner la signature

/li>

Les portefeuilles n’ont pas besoin d’implémenter des descripteurs pour commencer à utiliser la racine pivotante, mais ceux qui le font se donneront une meilleure base pour utiliser ultérieurement des fonctionnalités de racine pivotante plus avancées.

Libérations et candidats à la libération

Nouvelles versions et versions candidates pour les projets d’infrastructure Bitcoin populaires. Veuillez envisager de mettre à niveau vers de nouvelles versions ou d’aider à tester les versions candidates.

• LND 0.13.1-beta.rc1 est une version de maintenance avec des améliorations mineures et des corrections de bugs pour les fonctionnalités introduites dans 0.13.0-beta

Modifications notables du code et de la documentation

Changements notables cette semaine dans Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIP) et Lightning BOLT.

• Bitcoin Core #19651 permet au gestionnaire de clés de portefeuille de mettre à jour les descripteurs existants. Cela permet aux utilisateurs du portefeuille de modifier les étiquettes, d’étendre les plages de descripteurs, de réactiver les descripteurs inactifs et d’effectuer d’autres mises à jour à l’aide du RPC du portefeuille importdescriptors
• C-Lightning #4610 ajoute une option de ligne de commande –experimental-accept-extra-tlv-types qui permet aux utilisateurs de spécifier une liste de types TLV pairs que Lightningd doit traverser pour que les plugins soient gérés. Auparavant, Lightningd considérait que tous les messages TLV inconnus de type uniforme étaient invalides. Ce changement permet aux plugins de définir et de gérer leurs propres types de TLV personnalisés inconnus de Lightning
• Eclair #1854 ajoute la prise en charge du décodage et de la journalisation des messages d’avertissement envoyés par des pairs comme C-Lightning qui ont récemment implémenté des types de messages d’avertissement
• BIPs #1137 ajoute BIP86, qui suggère un schéma de dérivation de clé pour les sorties P2TR à clé unique. Le BIP a été résumé dans le bulletin de la semaine dernière
• Le BIP #1134 met à jour le BIP155 pour indiquer que le message de négociation de la fonctionnalité P2P sendaddr2 doit être envoyé chaque fois qu’un logiciel comprend les messages addr de la version 2, y compris dans les cas où le programme ne souhaite pas nécessairement recevoir des messages addr

Retrouvez l’article d’origine ici.