Le bulletin de cette semaine décrit comment l’empreinte des portefeuilles peut nuire à la confidentialité de payjoin et résume une proposition de format de métadonnées pour la sauvegarde de portefeuilles. Sont également incluses nos rubriques habituelles résumant les propositions et discussions sur la modification des règles de consensus de Bitcoin, annonçant de nouvelles versions et versions candidates, et décrivant les changements notables apportés aux logiciels populaires d’infrastructure Bitcoin.

Nouvelles

  • ● Risques de l’empreinte des portefeuilles pour la confidentialité de payjoin : Armin Sabouri a posté sur Delving Bitcoin comment des différences dans les implémentations de payjoin permettent de prendre l’empreinte des transactions payjoin et peuvent nuire à la confidentialité de payjoin.

    Sabouri indique que les transactions payjoin devraient paraître indiscernables de transactions standard à partie unique. Cependant, il peut y avoir des artefacts de transactions collaboratives :

    • Intra-transaction

      • Partitionner les entrées et sorties par propriétaire au sein d’une même transaction.

      • Différences dans l’encodage des entrées.

      • Longueur des entrées en octets.

    • Inter-transaction

      • Rétrospective : chaque entrée a été créée par une transaction antérieure qui porte sa propre empreinte.

      • Prospective : chaque sortie peut être dépensée dans une transaction future, révélant des empreintes.

    Il a ensuite examiné trois implémentations de payjoin : Samourai, la démo PDK, et Cake Wallet (envoyant vers Bull Bitcoin Mobile). Dans chacun de ces exemples, il trouve quelques divergences qui permettent de prendre l’empreinte de ces implémentations. Cela inclut, sans s’y limiter :

    • Différences dans les signatures d’entrée encodées.

    • L’octet SIGHASH_ALL inclus dans une entrée mais pas dans l’autre.

    • Attribution de la valeur des sorties.

    Sabouri conclut que, si certaines de ces empreintes de portefeuille sont triviales à éliminer, d’autres sont intrinsèques à un choix de conception particulier du portefeuille. Les développeurs de portefeuilles devraient être conscients de ces fuites potentielles de confidentialité lors de l’implémentation de payjoin dans leurs portefeuilles.

  • ● Projet de BIP pour un format de métadonnées de sauvegarde de portefeuille : Pythcoiner a posté sur la liste de diffusion Bitcoin-Dev une nouvelle proposition pour une structure commune de métadonnées de sauvegarde de portefeuille. Le projet de BIP, disponible dans BIPs #2130, spécifie une manière standard de stocker divers types de métadonnées, comme les descripteurs de compte, les clés, les étiquettes, les PSBT, et plus encore, permettant la compatibilité entre différentes implémentations de portefeuilles ainsi que des processus de migration et de récupération de portefeuille plus simples. Selon Pythcoiner, l’écosystème manque d’une spécification commune et cette proposition vise à combler cette lacune.

    D’un point de vue technique, le format proposé est un fichier texte encodé en UTF-8 contenant un unique objet JSON valide représentant la structure de sauvegarde. Le BIP énumère tous les différents champs pouvant être inclus dans l’objet JSON, précise que chacun d’eux est optionnel, et note que toute implémentation de portefeuille devrait être libre d’ignorer toute métadonnée jugée inutile.

Modification du consensus

Une nouvelle section mensuelle résumant les propositions et discussions sur la modification des règles de consensus de Bitcoin.

  • ● Compact Isogeny PQC peut remplacer les portefeuilles HD, l’ajustement de clé, les silent payments : Conduition a écrit sur Delving Bitcoin à propos de ses recherches sur l’adéquation de la cryptographie basée sur les isogénies (IBC) comme système cryptographique post-quantique pour Bitcoin. Alors que le problème du logarithme discret sur courbe elliptique (ECDLP) pourrait devenir non sécurisé dans un monde post-quantique, il n’y a rien de fondamentalement cassé dans les mathématiques des courbes elliptiques en général. Brièvement, une isogénie est une application d’une courbe elliptique vers une autre. L’hypothèse cryptographique de l’IBC est qu’il est difficile de calculer l’isogénie entre une courbe elliptique d’un type spécifique et une autre, alors qu’il est facile de produire une isogénie et la courbe vers laquelle elle applique depuis une courbe de base. Ainsi, les clés secrètes IBC sont des isogénies et les clés publiques sont les courbes obtenues.

    Comme avec les clés secrètes et publiques ECDLP, il est possible de calculer de nouvelles clés secrètes et de nouvelles clés publiques indépendamment à partir du même sel (par ex. une étape de dérivation BIP32) et que les clés secrètes résultantes signent correctement pour les clés publiques résultantes. Conduition appelle cela la « rerandomisation » et cela permet fondamentalement BIP32, BIP341 et BIP352 (avec probablement quelques innovations cryptographiques supplémentaires).

    À ce jour, il n’existe pas de protocoles d’agrégation de signatures pour l’IBC comme il en existe pour MuSig et FROST, et conduition lance un appel à l’action aux développeurs Bitcoin et cryptographes pour étudier ce qui pourrait être possible.

    Les clés et signatures dans les systèmes cryptographiques IBC connus font environ deux fois la taille des clés dans les systèmes cryptographiques dépendant de l’ECDLP. Bien plus petites que dans les systèmes cryptographiques basés sur le hachage ou sur les réseaux euclidiens. La vérification est coûteuse même sur des machines de bureau (de l’ordre de 1 milliseconde par vérification), dans la même gamme que les systèmes basés sur le hachage et sur les réseaux euclidiens.

  • ● Le budget varops et la feuille tapscript 0xc2 (alias “Script Restoration”) sont les BIP 440 et 441 : Rusty Russell a écrit sur la liste de diffusion Bitcoin-Dev que les deux premiers BIP de la Great Script Restoration (ou Grand Script Renaissance) ont été soumis pour l’attribution d’un numéro BIP. Ils ont ensuite reçu les numéros BIP 440 et 441 respectivement. BIP440 permet la restauration d’opcodes Script précédemment désactivés en construisant un système de comptabilité du coût de chaque opération qui garantit que le pire coût de validation de script au niveau d’un bloc ne peut pas dépasser le coût de validation d’un bloc contenant le pire nombre possible d’opérations de signature. BIP441 décrit la validation d’une nouvelle version de tapscript qui restaure les opcodes désactivés par Satoshi en 2010.

  • ● SHRIMPS : signatures post-quantiques de 2,5 Ko sur plusieurs appareils à état : Jonas Nick écrit sur Delving Bitcoin à propos d’une nouvelle construction de signature semi-étatique basée sur le hachage pour un Bitcoin post-quantique. SHRIMPS tire parti du fait que les tailles de signature SPHINCS+ évoluent avec le nombre maximal de signatures pour une clé donnée qui peuvent être produites tout en conservant un niveau de sécurité donné.

    Semblable au design SHRINCS, une clé SHRIMPS est composée de deux clés hachées ensemble. Dans ce cas, les deux clés sont des clés SPHINCS+ sans état, mais avec des jeux de paramètres différents. La première clé n’est sécurisée que pour un petit nombre de signatures et est destinée à être utilisée avec la première (ou les quelques premières) signatures de chaque appareil de signature avec lequel la clé est utilisée. La seconde clé est sécurisée pour un nombre bien plus important de signatures (effectivement illimité dans un contexte Bitcoin) et chaque appareil revient sur cette clé après un certain nombre (potentiellement choisi par l’utilisateur) de signatures depuis cet appareil. Il en résulte que, dans le cas d’usage courant de Bitcoin où une clé donnée (dont beaucoup peuvent être dérivées d’une seule graine) ne signe qu’un petit nombre de fois, presque toutes les signatures peuvent faire < 2,5 Ko tout en n’ayant toujours aucune limite effective sur le nombre total de signatures si une clé finit par être réutilisée de nombreuses fois, au prix de signatures plus tardives d’environ 7,5 Ko. SHRIMPS est semi-étatique dans le sens où aucun état global n’a besoin d’être conservé, mais chaque appareil de signature doit enregistrer quelques bits d’ état pour chaque clé SHRIMPS avec laquelle il signe ((jusqu’à un seul bit seulement, si seule la première signature pour chaque couple appareil–clé bénéficie de la signature compacte).

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.0rc2 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.04rc2 est la plus récente version candidate pour la prochaine version majeure de ce nœud LN populaire, poursuivant les mises à jour du splicing et les corrections de bogues des versions candidates précédentes.

  • ● BTCPay Server 2.3.7 est une version mineure de cette solution de paiement auto-hébergée qui fait migrer le projet vers .NET 10, ajoute des améliorations au passage en caisse des abonnements et des factures, ainsi que plusieurs autres améliorations et corrections de bogues. Les développeurs de plugins devraient suivre le guide de migration .NET 10 du projet lors de la mise à jour.

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 #32297 ajoute une option -ipcconnect à bitcoin-cli afin qu’il puisse se connecter à une instance bitcoin-node et la contrôler via une communication inter-processus (IPC) sur un socket Unix au lieu de HTTP lorsque Bitcoin Core est compilé avec ENABLE_IPC et que le nœud est démarré avec -ipcbind (voir les bulletins #320 et #369). Même lorsque -ipcconnect est omise, bitcoin-cli essaie d’abord l’IPC puis revient à HTTP si l’IPC n’est pas disponible. Cela fait partie du projet de séparation multiprocessus.

  • ● Bitcoin Core #34379 corrige un bogue où l’appel RPC gethdkeys (voir le Bulletin #297) avec private=true échouait si le portefeuille contenait un descripteur dont il possédait certaines clés privées mais pas toutes. Semblable au correctif pour listdescriptors (voir le Bulletin #389), cette PR renvoie les clés privées disponibles. Appeler gethdkeys private=true sur un portefeuille strictement en observation seule échoue toujours.

  • ● Eclair #3269 ajoute la récupération automatique de liquidité depuis des canaux inactifs. Lorsque le PeerScorer détecte que le volume total de paiements d’un canal dans les deux directions tombe en dessous de 5 % de sa capacité, il réduit progressivement les frais de relais jusqu’au minimum configuré. Si les frais sont au minimum depuis au moins cinq jours et que le volume n’a toujours pas repris, Eclair ferme le canal lorsqu’il est redondant avec ce pair. Les canaux ne sont fermés que si le nœud détient au moins 25 % des fonds et que le solde local dépasse le paramètre existant localBalanceClosingThreshold.

  • ● LDK #4486 fusionne le point de terminaison rbf_channel dans splice_channel comme point d’entrée unique à la fois pour les nouveaux splices et pour l’augmentation de frais d’un splice en cours. Lorsqu’un splice est déjà en cours, le FundingTemplate renvoyé par splice_channel contient PriorContribution afin que les utilisateurs puissent RBF le splice sans nouvelle sélection de pièces. Voir le Bulletin #397 pour un comportement RBF de splice connexe.

  • ● LDK #4428 ajoute la prise en charge de l’ouverture et de l’acceptation de canaux avec une réserve de canal nulle via une nouvelle méthode create_channel_to_trusted_peer_0reserve pour les pairs de confiance. Les canaux à réserve nulle permettent à la contrepartie de dépenser l’intégralité de son solde on-chain dans le canal. Cela est activé aussi bien pour les canaux utilisant des anchor outputs que pour les canaux de commitment sans frais (voir le Bulletin #371).

  • ● LND #9982, #10650 et #10693 renforcent la gestion des nonce MuSig2 sur le réseau pour les canaux taproot : ChannelReestablish gagne un champ LocalNonces afin que les pairs puissent coordonner plusieurs nonce pour les mises à jour liées au splicing, lnwire valide les nonce publics MuSig2 lors du décodage TLV pour les messages transportant des nonce, et le décodage de LocalNoncesData valide chaque entrée de nonce.

  • ● LND #10063 étend le flux de fermeture coopérative RBF aux canaux taproot simples en utilisant MuSig2. Les messages wire transportent des champs de nonce et de signature partielle spécifiques à taproot, et la machine à états de fermeture utilise des sessions MuSig2 avec un modèle de nonce juste-à-temps à travers shutdown, closing_complete et closing_sig (voir le Bulletin #347 pour le contexte sur le flux de fermeture coopérative RBF).

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.