Le bulletin de cette semaine décrit une mise à jour de la proposition sur les points d’ancrage éphémères et fournit un rapport d’une contribution de terrain sur Miniscript par un développeur travaillant chez Wizardsardine. 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

• ● Élimination de la malléabilité des dépenses d’ancrage éphémère : Gregory Sanders a publié sur le forum Delving Bitcoin une modification de la proposition concernant les points d’ancrage éphémères. Cette proposition permettrait aux transactions d’inclure une sortie de valeur nulle avec un script de sortie pouvant être dépensé par n’importe qui. Comme n’importe qui peut dépenser la sortie, n’importe qui peut augmenter les frais de transaction CPFP de la transaction qui a créé la sortie. Cela est pratique pour les protocoles de contrat multipartite tels que LN, où les transactions sont souvent signées avant qu’il soit possible de prédire avec précision le taux de frais qu’elles doivent payer. Les points d’ancrage éphémères permettent à n’importe quelle partie du contrat d’ajouter autant de frais qu’elle estime nécessaire. Si une autre partie, ou tout autre utilisateur pour une raison quelconque, souhaite ajouter des frais plus élevés, elle peut remplacer l’augmentation des frais CPFP par sa propre augmentation des frais CPFP à un taux plus élevé.

  Le script anyone-can-spend proposé est un script de sortie composé de l’équivalent de OP_TRUE, qui peut être dépensé par une entrée avec un script d’entrée vide. Comme l’a publié Sanders cette semaine, l’utilisation d’un script de sortie hérité signifie que la transaction enfant qui le dépense a un txid malléable, c’est-à-dire que n’importe quel mineur peut ajouter des données au script d’entrée pour modifier le txid de la transaction enfant. Il est donc déconseillé d’utiliser la transaction enfant pour autre chose que l’augmentation des frais, car même si elle est confirmée, elle peut être confirmée avec un txid différent qui invalide toutes les transactions petites-filles.

  Sanders suggère plutôt d’utiliser l’un des scripts de sortie qui avaient été réservés pour les futures mises à niveau de SegWit. Cela consomme légèrement plus d’espace dans le bloc—quatre octets pour SegWit contre un octet pour OP_TRUE nu—mais élimine tout problème concernant la malléabilité de la transaction. Après quelques discussions sur le fil, Sanders a proposé plus tard d’offrir les deux options : une version OP_TRUE pour ceux qui ne se soucient pas de la malléabilité et qui veulent minimiser la taille de la transaction, ainsi qu’une version SegWit légèrement plus grande mais qui n’autorise pas la mutation de la transaction enfant. Les discussions supplémentaires sur le fil se sont concentrées sur le choix des octets supplémentaires pour l’approche SegWit afin de créer une adresse bech32m mémorable.

Rapport de terrain : Un voyage avec Miniscript

Notre intérêt (pratique) pour miniscript a commencé au début de 2020 lorsque nous concevions Revault, une architecture de coffre-fort multipartie utilisant uniquement les primitives de script disponibles à l’époque.

Nous avons initialement présenté Revault en utilisant un ensemble fixe de participants. Nous avons rapidement rencontré des problèmes lorsque nous avons essayé de le généraliser à un plus grand nombre de participants dans un environnement de production.

• Sommes-nous vraiment sûrs que le script que nous avons utilisé dans la démonstration est sécurisé ? Est-il possible de le dépenser de toutes les manières annoncées ? N’y a-t-il aucune autre façon de le dépenser que celle annoncée ?
• Même s’il l’est, comment pouvons-nous le généraliser à un nombre variable de participants tout en le maintenant sécurisé ? Comment pouvons-nous appliquer des optimisations et nous assurer que le script résultant a les mêmes sémantiques ?
• De plus, Revault utilise des transactions pré-signées (pour appliquer des politiques de dépenses). Comment pouvons-nous connaître à l’avance le budget à allouer pour l’augmentation des frais en fonction de la configuration du script ? Comment pouvons-nous nous assurer que toute transaction dépensant ces scripts passera les vérifications de conformité les plus courantes ?
• Enfin, même en supposant que nos scripts correspondent aux sémantiques prévues et qu’ils sont toujours dépensables, comment pouvons-nous les dépenser concrètement ? Comment pouvons-nous produire un témoin conforme (“signer pour”) à chaque configuration possible ? Comment pouvons-nous rendre les dispositifs de signature matérielle compatibles avec nos scripts ?

Ces questions auraient constitué des obstacles majeurs si ce n’était pas pour miniscript. Deux personnes dans un garage ne vont pas écrire un logiciel qui crée un script à la volée, et espère le meilleur et se permettre d’appeler ça un portefeuille Bitcoin améliorant la sécurité. Nous voulions créer une entreprise autour du développement de Revault, mais nous n’obtiendrions pas de financement sans fournir une certaine assurance raisonnable à un investisseur que nous pourrions proposer un produit sûr sur le marché. Et nous ne pourrions pas résoudre tous ces problèmes d’ingénierie sans financement.

Entre en jeu miniscript, “un langage pour écrire (une partie de) Scripts Bitcoin de manière structurée, permettant l’analyse, la composition, la signature générique et plus encore. […] Il a une structure qui permet la composition. Il est très facile à analyser statiquement pour diverses propriétés (conditions de dépense, correction, propriétés de sécurité, malléabilité, …)”. C’est exactement ce dont nous avions besoin. Armés de cet outil puissant, nous pourrions offrir de meilleures garanties [0] à nos investisseurs, lever des fonds et commencer le développement de Revault.

À l’époque, miniscript était encore loin d’être une solution clé en main pour tout développeur d’application Bitcoin. (Si vous êtes un nouveau développeur Bitcoin lisant ceci après l’année 2023, oui, il fut un temps où nous écrivions les scripts Bitcoin À LA MAIN.) Nous avons dû intégrer miniscript dans Bitcoin Core (voir les PR #24147, #24148 et #24149), que nous avons utilisé comme backend du portefeuille Revault, et convaincre les fabricants de dispositifs de signature de l’implémenter dans leur firmware. Cette dernière partie s’est avérée la plus difficile.

C’était un problème de poule et d’œuf : les incitations étaient faibles pour les fabricants d’implémenter miniscript sans demande des utilisateurs. Et nous ne pouvions pas sortir Revault sans avoir des dispositifs de signature compatibles avec miniscript sans prise en charge de l’appareil de signature. Heureusement, ce cycle a finalement été brisé par Stepan Snigirev en mars 2021 en apportant la prise en charge des descripteurs miniscript à Specter DIY. Cependant, le Specter DIY a été pendant longtemps considéré comme un simple “prototype fonctionnel”, et Salvatore Ingala a apporté miniscript à un appareil de signature prêt pour la production pour la première fois en 2022 avec la nouvelle application Bitcoin pour le Ledger Nano S(+). L’application a été publiée en janvier 2023, ce qui nous a permis de publier le portefeuille Liana avec prise en charge de l’appareil de signature le plus populaire.

Il ne reste plus qu’un dernier développement pour conclure notre parcours miniscript. Liana est un portefeuille Bitcoin axé sur les options de récupération. Il permet de spécifier certaines conditions de récupération avec verrouillage temporel (par exemple, une clé de récupération tierce qui ne peut normalement pas dépenser les fonds, ou un multisig en déclin/ expansion). Miniscript était initialement disponible uniquement pour les scripts P2WSH. Près de 2 ans après l’activation de taproot, il est regrettable que vous deviez publier vos chemins de dépense de récupération on chain à chaque fois que vous faites une dépense. À cette fin, nous avons travaillé pour porter miniscript à tapscript (voir ici et ici).

L’avenir est prometteur. La plupart des appareils de signature ayant déjà implémenté ou étant en cours d’implémentation de miniscript (par exemple récemment Bitbox et Coldcard), les frameworks natifs de taproot et miniscript ayant été peaufinés, la contractualisation sur Bitcoin avec des primitives sécurisées est plus accessible que jamais.

Il est intéressant de noter comment le financement des outils et des frameworks Open Source réduit les barrières à l’entrée pour les entreprises innovantes qui peuvent désormais affronter la concurrence et, plus généralement, mettre en œuvre des projets. Cette tendance, qui s’est accélérée ces dernières années, nous permet d’être optimistes quant à l’avenir de cet espace.

[0] Il y avait toujours un risque, bien sûr. Mais au moins, nous étions confiants de pouvoir passer à l’étape off-chain. Celle-ci s’est avérée (comme prévu) plus difficile.

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 0.17.1-beta est une version de maintenance de cette implémentation de nœud LN qui comprend plusieurs corrections de bugs et améliorations mineures.

• ● Bitcoin Core 26.0rc2 est une version candidate pour la prochaine version majeure de l’implémentation principale du nœud complet. Il existe un guide de test et une réunion prévue du Bitcoin Core PR Review Club dédiée aux tests le 15 novembre 2023.

• ● Core Lightning 23.11rc1 est une version candidate pour la prochaine version majeure de cette implémentation de nœud LN.

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 de Bitcoin (BIP), Lightning BOLTs et Bitcoin Inquisition.

• ● Bitcoin Core #28207 met à jour la façon dont le mempool est stocké sur le disque (ce qui se produit normalement lors de l’arrêt du nœud, mais peut également être déclenché par l’API savemempool). Auparavant, il était stocké dans une sérialisation simple des données sous-jacentes. Maintenant, cette structure sérialisée est XORée par une valeur aléatoire générée indépendamment par chaque nœud, obfusquant les données. Elle est XORée par la même valeur lors du chargement pour supprimer l’obscurcissement. L’obscurcissement empêche quelqu’un de pouvoir mettre certaines données dans une transaction pour obtenir une séquence particulière d’octets dans les données du mempool enregistrées, ce qui pourrait amener des programmes tels que les scanners de virus à signaler les données du mempool enregistrées comme dangereuses. La même méthode était précédemment appliquée au stockage de l’ensemble UTXO dans PR #6650. Tout logiciel qui a besoin de lire les données du mempool à partir du disque devrait pouvoir appliquer facilement lui-même l’opération XOR, ou utiliser le paramètre de configuration -persistmempoolv1 pour demander l’enregistrement dans le format non obscurci. Notez qu’on prévoit de supprimer le paramètre de configuration de compatibilité ascendante dans une version future.

• ● LDK #2715 permet à un nœud d’accepter facultativement une valeur HTLC plus petite que celle censée être livrée. Cela est utile lorsque le pair amont paie le nœud via un nouveau canal JIT, ce qui coûte au pair amont des frais de transaction on-chain qu’il déduira s’il le souhaite du montant de l’HTLC payé au nœud. Voir Newsletter #257 pour l’implémentation précédente de la partie amont de cette fonctionnalité dans LDK.