Le bulletin de cette semaine annonce une ébauche de BIP pour référencer des clés non dépensables dans les descripteurs, examine comment les implémentations utilisent PSBTv2, et corrige en détail notre description de la semaine dernière d’un nouveau protocole DLC offchain. Il contient également nos sections régulières avec des descriptions des changements apportés aux clients et services populaires, des annonces de nouvelles versions et de versions candidates avec des résumés des changements notables apportés aux logiciels d’infrastructure Bitcoin populaires.

Nouvelles

  • ● Ébauche de BIP pour les clés non dépensables dans les descripteurs : Andrew Toth a posté sur Delving Bitcoin et la liste de diffusion Bitcoin-Dev une ébauche de BIP pour référencer des clés vérifiablement non dépensables dans les descripteurs. Cela fait suite à une discussion précédente (voir le Bulletin #283). Utiliser une clé vérifiablement non dépensable, également appelée point nothing up my sleeve (NUMS), est particulièrement pertinent pour la clé interne taproot. S’il n’est pas possible de créer une dépense par keypath à l’aide de la clé interne, seule une dépense par scriptpath à l’aide d’une tapleaf est possible. (par exemple, en utilisant un tapscript).

    Au moment où nous écrivons ces lignes, une discussion active a lieu sur la PR du BIP en avant projet.

  • ● Tests d’intégration PSBTv2 : Sjors Provoost a démandé sur la liste de diffusion Bitcoin-Dev qu’on lui communique les logiciels ayant implémenté le support pour la version 2 des PSBTs (voir le Bulletin #141) afin de tester PR ajoutant sa gestion par Bitcoin Core. Une liste mise à jour des logiciels l’utilisant peut être trouvée sur Bitcoin Stack Exchange. Nous avons trouvé deux réponses intéressantes :

  • ● PSBTv2 Merklisé : Salvatore Ingala explique que l’application Bitcoin Ledger convertit les champs d’un PSBTv2 en un arbre de Merkle et envoie initialement uniquement la racine à un dispositif de signature matériel Ledger. Lorsque des champs spécifiques sont nécessaires, ils sont envoyés avec la preuve de Merkle appropriée. Cela permet au dispositif de travailler en toute sécurité avec chaque morceau d’information indépendamment sans avoir à stocker l’ensemble de la PSBT dans sa mémoire limitée. Cela est possible avec PSBTv2 car elle a déjà les parties de la transaction non signée séparées en champs distincts ; pour le format PSBT original (v0), cela nécessitait un traitement supplémentaire.

  • ● Paiements silencieux PSBTv2 : Le BIP352 spécifiant silent payments dépend explicitement de la spécification BIP370 de PSBTv2. Andrew Toth explique que silent payments a besoin du champ PSBT_OUT_SCRIPT de v2 car le script de sortie à utiliser ne peut pas être connu pour silent payments tant que tous les signataires n’ont pas traité la PSBT.

  • ● Correction à propos des DLC offchain : dans notre description des DLC offchain dans le bulletin de la semaine dernière, nous avons confondu le nouveau schéma proposé par le développeur Conduition avec les schémas de DLC offchain précédemment publiés et implémentés. Il y a une différence significative et intéressante :

    • Le protocole DLC channels mentionné dans les Bulletins #174 et #260 utilise un mécanisme similaire à LN-Penalty commit-and-revoke où les parties s’engagent sur un nouvel état en le signant puis révoquent l’ancien état en libérant un secret qui permet à leur version privée de l’ancien état d’être complètement dépensée par leur contrepartie si elle est publiée sur la chaîne. Cela permet de renouveler un DLC par interaction entre les parties. Par exemple, Alice et Bob font ce qui suit :

      1. S’accordent immédiatement sur un DLC pour le prix BTCUSD dans un mois.

      2. Trois semaines plus tard, s’accordent sur un DLC pour le prix BTCUSD dans deux mois et révoquent le DLC précédent.

      • Le nouveau protocole DLC factories révoque automatiquement la capacité des deux parties à publier des états onchain au moment où le contrat arrive à maturité en permettant à toute attestation d’oracle pour le contrat de servir de secret qui permet à un état privé d’être complètement dépensé par une contrepartie s’il est publié onchain. En effet, cela annule automatiquement les anciens états, ce qui permet de signer des DLC successifs au début de la factory sans aucune interaction supplémentaire requise. Par exemple, Alice et Bob font ce qui suit :

      1. S’accordent immédiatement sur un DLC pour le prix BTCUSD dans un mois.

      2. S’accordent également immédiatement sur un DLC pour le prix BTCUSD dans deux mois avec un timelock qui empêche sa publication jusqu’à un mois à partir de maintenant. Ils peuvent répéter cela pour le troisième mois, le quatrième, etc…

    Dans le protocole DLC channels, Alice et Bob ne peuvent pas créer le deuxième contrat tant qu’ils ne sont pas prêts à révoquer le premier contrat, ce qui nécessite une interaction entre eux à ce moment-là. Dans le protocole DLC factories, tous les contrats peuvent être créés au moment de la création de la factory et aucune interaction supplémentaire n’est requise ; cependant, l’une ou l’autre partie peut toujours interrompre une série de contrats en allant onchain avec la version actuellement sûre et publiable.

    Si les participants à la factory sont capables d’interagir après l’établissement du contrat, ils peuvent le prolonger, mais ils ne peuvent pas décider d’utiliser un contrat différent ou des oracles différents avant que tous les contrats précédemment signés aient atteint leur maturité (à moins d’aller onchain). Bien qu’il soit peut-être possible d’éliminer cet inconvénient, c’est actuellement le compromis pour la réduction de l’interactivité par rapport au protocole DLC channels, qui permet des changements de contrat arbitraires à tout moment par révocation mutuelle.

    Nous remercions Conduition de nous avoir informés de notre erreur dans le bulletin de la semaine dernière et d’avoir patiemment répondu à nos questions.

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.

Mises à jour et versions candidates

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

  • ● BTCPay Server 2.0.6 contient un “correctif de sécurité pour les commerçants utilisant les remboursements/paiements tirés onchain avec des processeurs de paiement automatisés.” Sont également inclus plusieurs nouvelles fonctionnalités et corrections de bugs.

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 #31397 améliore le processus de résolution des orphelins en suivant et en utilisant tous les pairs potentiels pouvant fournir les transactions parentes manquantes. Auparavant, le processus de résolution dépendait uniquement du pair qui avait initialement fourni la transaction orpheline. Si le pair ne répondait pas ou renvoyait un message notfound, il n’y avait pas de mécanisme de nouvelle tentative, entraînant probablement des échecs de téléchargement de la transaction. La nouvelle approche tente de télécharger la transaction parente de tous les pairs candidats tout en maintenant l’efficacité de la bande passante, la résistance à la censure et un équilibrage de charge efficace. C’est particulièrement bénéfique pour le relais de paquets un-parent un-enfant (1p1c) package relay, et cela prépare le terrain pour le relais de paquets d’ancêtres initié par le récepteur de BIP331.

  • ● Eclair #2896 permet de stocker la signature partielle d’un pair MuSig2 au lieu d’une signature multisig traditionnelle 2-sur-2, comme prérequis pour une future mise en œuvre de canaux taproot simples. Stocker cela permet à un nœud de diffuser unilatéralement une transaction d’engagement lorsque nécessaire.

  • ● LDK #3408 introduit des utilitaires pour créer des factures statiques et leurs offres correspondantes dans le ChannelManager, pour supporter les paiements asynchrones dans BOLT12 tel que spécifié dans BOLTs #1149. Contrairement à l’utilitaire de création d’offre régulier, qui nécessite que le destinataire soit en ligne pour servir les demandes de facture, le nouvel utilitaire accommode les destinataires qui sont fréquemment hors ligne. Cette PR ajoute également les tests manquants pour le paiement de factures statiques (voir le Bulletin #321), et assure que les demandes de facture sont récupérables lorsque le destinataire se reconnecte en ligne.

  • ● LND #9405 rend le paramètre ProofMatureDelta configurable, ce qui détermine le nombre de confirmations nécessaires avant qu’une annonce de canal soit traitée dans le réseau de gossip. La valeur par défaut est de 6.