Le bulletin de cette semaine décrit une idée de nœuds Lightning MuSig2 imbriqués et résume un projet vérifiant formellement la multiplication scalaire modulaire de secp256k1. Sont également incluses nos sections régulières décrivant les changements récents dans les services et logiciels clients, annonçant de nouvelles versions et versions candidates, et résumant les changements notables apportés aux logiciels populaires d’infrastructure Bitcoin.

Nouvelles

• ● Discussion sur l’utilisation de MuSig2 imbriqué dans le Lightning Network : ZmnSCPxj a posté sur Delving Bitcoin à propos de l’idée de créer des nœuds Lightning multisignatures k-sur-n en tirant parti de MuSig2 imbriqué comme discuté dans un récent article.

  Selon ZmnSCPxj, le besoin d’un schéma de signature k-sur-n dans Lightning découle du fait que de grands détenteurs souhaitent fournir leur liquidité au réseau en échange de frais. Ces grands détenteurs peuvent avoir besoin de fortes garanties quant à la sécurité de leurs fonds, ce qu’une seule clé peut ne pas offrir. À la place, un schéma k-sur-n fournirait la sécurité requise tant que moins de k clés sont compromises.

  À ce jour, les spécifications BOLTs ne permettent pas de manière sûre d’implémenter un schéma multisig k-sur-n, le principal obstacle étant la clé de révocation. Selon les BOLTs, la clé de révocation est créée à l’aide d’une shachain, qui, en raison de ses caractéristiques, n’est pas adaptée à une utilisation avec des schémas multisig k-sur-n.

  ZmnSCPxj propose une modification des spécifications BOLTs pour rendre facultative pour les nœuds la validation shachain des clés de révocation des parties du canal en signalant une nouvelle paire de bits de fonctionnalité, nommée no_more_shachains, dans globalfeatures et localfeatures. Un bit impair signalerait que le nœud n’effectuera pas de validation shachain sur la contrepartie, tout en fournissant encore des clés de révocation valides selon shachain afin de conserver la compatibilité avec les nœuds historiques. Un bit pair signalerait que le nœud ne validera ni ne fournira de clés de révocation valides selon shachain. Le premier bit serait utilisé par les nœuds passerelles, tels que définis par ZmnSCPxj, qui connecteraient le reste du réseau aux nœuds k-sur-n, ceux qui utilisent le bit pair.

  Enfin, ZmnSCPxj souligne comment cette proposition présenterait un compromis majeur, à savoir les besoins de stockage pour les clés de révocation. En effet, les nœuds devraient stocker des clés de révocation individuelles au lieu de la représentation compacte shachain, triplant effectivement l’espace disque nécessaire.

• ● Vérification formelle de la multiplication scalaire modulaire de secp256k1 : Remix7531 a posté sur la liste de diffusion Bitcoin-Dev à propos de la vérification formelle de la multiplication scalaire modulaire de secp256k1. Le projet démontre que la vérification formelle d’un sous-ensemble de bitcoin-core/secp256k1 est pratique.

  Dans le code source secp256k1-scalar-fv-test, Remix7531 prend du vrai code C de la bibliothèque et prouve sa correction par rapport à une spécification mathématique formelle à l’aide de Rocq et du Verified Software Toolchain (VST). La formalisation avec Rocq peut prouver l’absence d’erreurs mémoire, la correction par rapport à une spécification, et la terminaison.

  Il prévoit de porter la preuve existante de multiplication scalaire vers RefinedC, ce qui fournirait une comparaison directe des deux frameworks sur le même code vérifié. En outre, du côté de la vérification, la prochaine cible est l’algorithme de Pippenger pour la multiplication multi-scalaire, qui est utilisé pour la vérification par lot des signatures.

Changements dans les services et logiciels clients

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

• ● Coldcard 6.5.0 ajoute MuSig2 et miniscript : Coldcard 6.5.0 ajoute la prise en charge de la signature MuSig2, des capacités de preuve de réserve BIP322, et des fonctionnalités supplémentaires miniscript et taproot, y compris la prise en charge de tapscript pour jusqu’à huit feuilles.

• ● Frigate 1.4.0 publié : Frigate v1.4.0, un serveur Electrum expérimental pour le balayage de silent payments (voir le bulletin #389), utilise désormais la bibliothèque UltrafastSecp256k1 conjointement avec des calculs GPU modernes pour réduire le temps de balayage de quelques mois de blocs d’une heure à une demi-seconde.

• ● Mises à jour de Bitcoin Backbone : Bitcoin Backbone a publié plusieurs mises à jour ajoutant la prise en charge de compact block BIP152, des améliorations de la gestion des transactions et des adresses, ainsi que les bases d’une interface multiprocessus (voir le bulletin #368). L’annonce propose également des extensions de l’API Bitcoin Kernel pour la vérification autonome des en-têtes et la validation des transactions.

• ● Utreexod 0.5 publié : Utreexod v0.5 introduit l’IBD en utilisant SwiftSync, qui utilise l’agrégation cryptographique pour éliminer le besoin de télécharger et vérifier les preuves d’inclusion de l’accumulateur pendant l’IBD, et élimine les données supplémentaires téléchargées par les nœuds à état compact pendant l’IBD de 1,4 To à ~200 Go, avec d’autres réductions possibles grâce à la mise en cache des preuves.

• ● Floresta 0.9.0 publié : Floresta v0.9.0 aligne son réseau P2P avec le BIP183 pour l’échange de preuves UTXO, et remplace libbitcoinconsensus par Bitcoin Kernel pour une validation des scripts environ 15x plus rapide, parmi d’autres changements.

Mises à jour et versions candidates

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

• ● Bitcoin Core 31.0rc4 est une version candidate pour la prochaine version majeure de l’implémentation de nœud complet prédominante. Un guide de test est disponible.

• ● Core Lightning 26.04rc3 est la plus récente version candidate pour la prochaine version majeure de ce nœud LN populaire, poursuivant les mises à jour de splicing et les corrections de bogues des candidats précédents.

Changements notables dans le code et la documentation

Changements récents notables dans Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, et BINANAs.

• ● Bitcoin Core #34401 étend la prise en charge de btck_BlockHeader ajoutée à l’API C libbitcoinkernel (voir les bulletins #380 et #390) en ajoutant une méthode pour sérialiser un en-tête de bloc dans son encodage standard en octets. Cela permet aux programmes externes utilisant l’API C de stocker, transmettre ou comparer des en-têtes sérialisés sans avoir besoin de code de sérialisation séparé.

• ● Bitcoin Core #35032 cesse de stocker dans addrman, le gestionnaire d’adresses de pairs de Bitcoin Core, les adresses réseau apprises lors de l’utilisation de l’option privatebroadcast (voir le bulletin #388) avec le RPC sendrawtransaction. L’option privatebroadcast permet aux utilisateurs de diffuser des transactions via des connexions Tor ou I2P de courte durée, ou via le proxy Tor vers des pairs IPv4/IPv6.

• ● Core Lightning #9021 active le splicing par défaut en le retirant de son statut expérimental, à la suite de l’intégration du protocole de splicing dans la spécification BOLTs (voir le bulletin #398).

• ● Core Lightning #9046 augmente la valeur supposée de final_cltv_expiry (le delta d’expiration CLTV pour le dernier saut) pour les paiements keysend de 22 à 42 blocs afin de correspondre à la valeur de LDK, restaurant l’interopérabilité.

• ● LDK #4515 fait passer les canaux à engagement sans frais (voir le bulletin #371) du bit de fonctionnalité expérimental au bit de fonctionnalité de production. Les canaux à engagement sans frais remplacent les deux sorties d’ancrage par une sortie partagée Pay-to-Anchor (P2A), plafonnée à une valeur de 240 sats.

• ● LDK #4558 applique aux paiements multipath keysend payments le délai d’expiration côté destinataire existant pour les paiements incomplets. Auparavant, les MPP keysend incomplets pouvaient rester en attente jusqu’à l’expiration CLTV, immobilisant des emplacements HTLC au lieu d’échouer après la période normale d’expiration.

• ● LND #9985 ajoute une prise en charge de bout en bout pour les simple taproot channels de production avec un type d’engagement distinct (SIMPLE_TAPROOT_FINAL) et les bits de fonctionnalité de production 80/81. La version de production utilise des tapscripts optimisés qui préfèrent OP_CHECKSIGVERIFY à OP_CHECKSIG+OP_DROP, et ajoute une gestion des nonces basée sur une map dans revoke_and_ack, indexée par txid de financement, comme base pour un futur splicing.

• ● BTCPay Server #7250 ajoute la prise en charge de LUD-21 en introduisant un point de terminaison optionnel non authentifié nommé verify qui permet à des services externes de vérifier si une facture BOLT11 créée via LNURL-pay a été réglée.

• ● BIPs #2089 publie BIP376, qui définit de nouveaux champs par entrée PSBTv2 pour transporter les données de tweak BIP352 nécessaires pour signer et dépenser des sorties de silent payment, ainsi qu’un champ optionnel de dérivation de clé de dépense BIP32 compatible avec les clés de dépense de 33 octets de BIP352. Cela complète BIP375, qui spécifie comment créer des sorties de silent payment à l’aide de PSBTs (voir le bulletin #337).

Vous en voulez plus?

Pour plus de discussions sur les sujets mentionnés dans ce bulletin, rejoignez-nous pour le récapitulatif hebdomadaire Bitcoin Optech sur Riverside.fm à 16:30 UTC le jeudi (le jour suivant la publication de la newsletter). La discussion est également enregistrée et sera disponible sur notre page de podcasts.