Silent Payments

by
Nicolas Cantu
My articles My books
Follow on:

Présentation du BIP 352 : une des principales évolutions de Bitcoin, très importante pour la protection des utilisateurs et donc pour la survie de Bitcoin (selon moi). Merci Ruben et Josie pour le travail accompli, merci Sosthene et tous ceux qui implémentent. Accélérons ces développements !

Introduction

Utiliser une nouvelle adresse pour chaque transaction Bitcoin est un aspect crucial pour maintenir la confidentialité.

Par exemple, si vous prenez un verre dans un bar et que vous payez en Bitcoin (mainchain), le patron du bar pourrait connaître le montant de vos fonds. Un complice pourrait alors vous attendre à la sortie, car le lien entre vos adresses est « facile » à établir, surtout si elles sont réutilisées. Dans ce cas, vous auriez probablement dû privilégier l’usage du Lightning Network. Cependant, le problème à résoudre est bien celui-là : mieux protéger les utilisateurs de Bitcoin des actes illicites qu’induisent les moyens d’analyse et de recoupement avec une identité (tous services confondus, privés et publics). C’est aussi une réponse très pratique pour les dons, permettant de soutenir des initiatives et des personnes de façon plus confidentielle. À noter que l’Human Rights Foundation a subventionné les développeurs autour de Silent Payments, notamment pour la liberté économique des femmes dans le monde.

La protection de la vie privée est difficile et risquée. Certains développeurs sont menacés par les moyens qu’ils offrent au monde, et le poids colossal de Bitcoin doit, selon moi, abriter ces développements en « layer 1 », au cœur non contestable du protocole.

Les choix de design technique

Silent Payments continue des travaux sur BIP47 notamment mais en levant leurs limites (voir le lexique avec les diverses propositions précédentes). Silent Payments propose une approche différente depuis les « Stealth Payments » et le tweak d’adresses vus par exemple sur RGB. Ce qui est très élégant avec Silent Payments, c’est qu’une transaction contient une transaction absolument classique et sans OP_RETURN particulier (donc sans surcoût), avec à la fois un paiement, une notification de paiement et un secret partagé. Ces avantages impliquent cependant que les portefeuilles scannent la blockchain afin de détecter les paiements et de gérer deux clés privées : une pour la dépense des fonds et une pour le scan des blocs. Cette exigence supplémentaire est généralement réalisable pour les nœuds complets, mais pose un défi pour les clients légers, bien qu’il soit possible aujourd’hui de mettre en œuvre un client léger préservant la confidentialité au coût d’une bande passante accrue, par exemple avec un Electrs modifié. La conception garde à l’esprit les transactions collaboratives telles que CoinJoins et les entrées avec des clés MuSig et FROST, mais il est recommandé que les clés de toutes les entrées d’une transaction appartiennent à la même entité, car il n’y a aucune preuve formelle que le protocole est sécurisé dans un contexte collaboratif, pour l’instant (voir le chapitre des questions). Ainsi, cette proposition (BIP352) vise à résoudre les limitations de ces approches actuelles en présentant une solution qui élimine le besoin d’interaction, élimine le besoin de notifications et protège la confidentialité de l’expéditeur et du destinataire.

Le principe de fonctionnement

Les adresses Silent Payments permettent à l’émetteur de dissimuler dans des adresses composites un secret que seul le destinataire saura reconnaître, car il lui permet de réaliser une dépense. Les adresses ainsi « tweakées », mais de longueur classique, permettent de générer des adresses d’émetteur et de récepteur intégrant des composants privés de l’émetteur et publics du destinataire. En parcourant toutes les transactions d’un bloc (ou de la mempool), le destinataire saura reconnaître si une transaction lui est destinée et en extraire ses outputs dépensables.

Envoi d’une transaction Silent Payments

Lorsque Alice envoie des fonds à Bob, elle prend trois clés et crée une adresse unique à usage unique (code de paiement) que seul Bob peut contrôler. Ces trois clés sont :

1. La clé publique de la ou des sorties qu’Alice veut envoyer à Bob,
2. La clé publique de Bob dans son code de paiement réutilisable, et
3. Un secret partagé (généré en utilisant la clé publique Silent Payment et la clé privée de l’UTXO de l’utilisateur en utilisant ECDH) que seuls Alice et Bob peuvent connaître.

Ces trois clés se combinent en une adresse Taproot unique et à usage unique que Bob peut alors valider et dépenser, permettant à Alice de générer pratiquement des adresses infinies sans aucune communication avec Bob.

L’adresse Taproot unique résultante fait que le paiement apparaît exactement comme tout autre paiement Taproot sur la chaîne, empêchant ainsi un observateur externe de savoir que des transactions Silent Payment ont été utilisées, et encore moins de lier les paiements à une adresse Silent Payment spécifique.

Ce schéma illustre le processus d’envoi d’une transaction Silent Payments entre Alice (l’expéditrice) et Bob (le destinataire) en utilisant des techniques cryptographiques avancées.

Partie Gauche (les données connues d’Alice concernant Alice) :

• Lexicographically Smallest Outpoint : Alice commence par identifier l’outpoint le plus petit lexicographiquement parmi les entrées qu’elle souhaite utiliser. « Lexicographiquement » fait référence à l’ordre des mots ou des chaînes de caractères tel qu’il est défini par le dictionnaire ou par l’ordre alphabétique. Cet outpoint est ajouté afin de ne pas pouvoir retomber plusieurs fois sur le même résultat avec les mêmes clés.
• Hash Function : Elle applique une fonction de hachage à cet outpoint pour obtenir une valeur hachée.
• Scalar Addition : Elle additionne les clés privées des entrées pour obtenir une clé privée agrégée (a_agg).
• EC(DH) Private Key : Cette clé privée agrégée est utilisée comme clé privée EC(DH) (Diffie-Hellman sur courbe elliptique).

Partie Droite (les données connues d’Alice concernant Bob) :

• Index k : Un index est utilisé pour dériver plusieurs sorties pour le même destinataire.
• EC(DH) Shared Secret : Alice et Bob génèrent un secret partagé en utilisant la clé publique Silent Payment et la clé privée de l’UTXO d’Alice via ECDH.
• Hash Function : Le secret partagé est haché pour obtenir une valeur tweak (valeur de réglage) privée.
• Tweak Value : Cette valeur tweak est ensuite transformée en une clé publique tweak.
• Key Addition : La clé publique tweak est ajoutée à la clé de dépense de Bob pour obtenir la clé de sortie Taproot.
• Taproot Output Key : Cette clé de sortie est utilisée pour créer une adresse unique et à usage unique que seul Bob peut dépenser.

Explication détaillée :

• Alice génère une adresse unique :

Elle utilise une clé publique des sorties, la clé publique de Bob et un secret partagé pour créer une adresse Taproot unique.

La combinaison de ces clés garantit que chaque transaction est unique et non réutilisable.

• Bob vérifie les transactions :

Bob utilise sa clé privée de balayage pour vérifier chaque transaction sur la blockchain.

S’il trouve une correspondance, il peut dépenser les fonds ; sinon, il passe à la transaction suivante :

Importance de chaque étape :

• Prévention de la réutilisation d’adresses : La plus petite sortie lexicographique et le hachage empêchent la réutilisation accidentelle d’adresses.
• Secret partagé : Utilisation de ECDH pour garantir que seul Bob peut déchiffrer et dépenser les fonds.
• Indexation et réglage des clés : Permet de dériver plusieurs sorties pour le même destinataire tout en maintenant la confidentialité.

Ce processus assure une confidentialité accrue pour l’expéditeur et le destinataire en rendant chaque adresse de transaction unique et difficile à tracer par des observateurs externes.

Sur la chaîne, vous verrez des transactions Bitcoin normales qui semblent être des transactions Taproot ordinaires. Cependant, chaque adresse utilisée pour ces transactions est unique et ne se répète jamais, même si elles sont générées à partir de la même adresse Silent Payments.

Détails Techniques :

• Adresses Taproot Uniques : Les adresses Taproot générées pour chaque paiement sont uniques et apparaissent comme des adresses normales Taproot sur la blockchain.
• Aucune réutilisation d’adresses : Chaque transaction utilise une adresse unique dérivée cryptographiquement, évitant ainsi la réutilisation d’adresses qui pourrait compromettre la confidentialité.
• Confidentialité renforcée : Pour un observateur externe, il est impossible de distinguer une transaction utilisant des Silent Payments d’une transaction Taproot ordinaire, rendant le suivi des transactions plus difficile.

Exemple d’adresse de Silent Payments :

• sp1qqweplq6ylpfrzuq6hfznzmv28djsraupudz0s0dclyt8erh70pgwxqkz2ydatksrdzf770umsntsmcjp4kcz7jqu03jeszh0gdmpjzmrf5u4zh0c

Exemple d’adresse Taproot sur la Blockchain :

• bc1pftjlgdq0ufhq7qwd0atxhrjhlnpmc8v4x50tgytygzk5rz339u6qngunq4

Réception d’une transaction Silent Payments

Lorsque Bob veut vérifier les fonds reçus, il regarde sur la chaîne pour une éventuelle transaction Silent Payment le concernant ; pour cela, il construit une clé agrégée de toutes ses entrées et la combine avec la clé privée de scan de son adresse Silent Payments (code de paiement).

Si la combinaison correspond à une sortie de cette transaction, il peut la dépenser et donc cette transaction lui est destinée.

Sinon, il peut ignorer cette transaction et passer à la suivante, jusqu’à ce qu’il ait scanné l’ensemble des UTXO potentiels avec une transaction Silent Payment.

Ce schéma illustre le processus de réception d’une transaction Silent Payment par Bob après qu’Alice a envoyé des fonds en utilisant des techniques cryptographiques avancées. C’est, pour la première partie, l’inverse de l’envoi. Ensuite, on utilise les scripts Taproot pour la dépense.

Partie Gauche (Alice) :

• Lexicographically Smallest Outpoint : Alice commence par identifier l’outpoint le plus petit lexicographiquement parmi les entrées qu’elle souhaite utiliser. « Lexicographiquement » fait référence à l’ordre des mots ou des chaînes de caractères tel qu’il est défini par le dictionnaire ou par l’ordre alphabétique. Cet outpoint est ajouté afin de ne pas pouvoir retomber plusieurs fois sur le même résultat avec les mêmes clés.
• Hash Function : Elle applique une fonction de hachage à cet outpoint pour obtenir une valeur hachée.
• Point Addition : Alice additionne les clés publiques des entrées pour obtenir une clé publique agrégée (a_agg).
• EC(DH) Public Key : Cette clé publique agrégée est utilisée comme clé publique EC(DH) (Diffie-Hellman sur courbe elliptique).

Partie Droite (Alice et Bob) :

• Index k : Un index est utilisé pour dériver plusieurs sorties pour le même destinataire.
• EC(DH) Shared Secret : Alice et Bob génèrent un secret partagé en utilisant la clé publique Silent Payment et la clé privée de l’UTXO d’Alice via ECDH.
• Hash Function : Le secret partagé est haché pour obtenir une valeur tweak (valeur de réglage) privée.
• Tweak Value : Cette valeur tweak est ensuite transformée en une clé publique tweak.
• Key Addition : La clé publique tweak est ajoutée à la clé de dépense de Bob pour obtenir la clé de sortie Taproot.
• Taproot Output Key : Cette clé de sortie est utilisée pour créer une adresse unique et à usage unique que seul Bob peut dépenser.

Fonctionnement détaillé de Bob pour recevoir des paiements :

• Scan Key : Bob utilise sa clé privée de balayage pour vérifier chaque transaction sur la blockchain.
• Label (Optionnel) : Bob peut utiliser des labels pour identifier les transactions entrantes, par exemple, pour différentes entreprises ou comptes clients.
• Spend Key : La clé de dépense de Bob est utilisée dans l’addition de clés avec la clé tweak publique.
• Key Addition : Bob combine la clé tweak publique avec sa clé de dépense pour obtenir la clé de sortie Taproot.
• Taproot Output Key : Bob vérifie les transactions sur la blockchain en recherchant des sorties Taproot qui correspondent à cette clé.
• Scalar Addition : Si une sortie correspond, Bob peut utiliser sa clé privée de dépense pour dépenser les fonds reçus.

Importance des étapes :

• Prévention de la réutilisation d’adresses : La plus petite sortie lexicographique et le hachage empêchent la réutilisation accidentelle d’adresses.
• Secret partagé : Utilisation de ECDH pour garantir que seul Bob peut déchiffrer et dépenser les fonds.
• Indexation et réglage des clés : Permet de dériver plusieurs sorties pour le même destinataire tout en maintenant la confidentialité.

Ce processus garantit une confidentialité accrue pour l’expéditeur et le destinataire en rendant chaque adresse de transaction unique et difficile à tracer par des observateurs externes.

Scan des blocs pour détecter une transaction Silent Payments reçue

Parce que Bob ne peut pas pré-générer toutes les adresses de réception Silent Payment, il doit continuer à vérifier pour trouver de nouveaux paiements à partir du moment où il a généré le code de paiement (souvent appelée date anniversaire du portefeuille, mais cela pourrait changer avec l’expiration des adresses Silent Payments pour les renouveler par précaution).

Comme ce scan est relativement coûteux, les transactions Silent Payments nécessitent plus de calcul et de bande passante qu’un serveur standard de type Electrum. Le portefeuille Bitcoin moyen aujourd’hui devra se connecter à un nouveau type de serveur (https://github.com/Sosthene00/electrs/tree/sp_tweaks) qui fournit les données « tweak » nécessaires pour qu’un portefeuille vérifie chaque transaction potentielle par lui-même.

Il s’agit de 33 octets de données (appelées « outpoint », c’est-à-dire les TxId des sorties utilisées associées à l’index de la sortie) par sortie potentielle du bloc, pour que Bob puisse effectuer un Diffie-Hellman, c’est-à-dire un calcul ECDH, pour vérifier s’il détient la sortie (qu’il peut alors dépenser comme vu précédemment). Ces informations sur les sorties potentielles sont les mêmes pour tous, il s’agit de données publiques du bloc. Le principal avantage de cette approche est qu’elle offre une excellente confidentialité (même pour les portefeuilles légers) car le back-end du portefeuille ne sait pas quels outputs appartiennent à un client léger (il les envoie tous).

Ces informations ne sont pas collectées sur les transactions ne pouvant pas être des transactions Silent Payments :

• Sorties non-Taproot
• Sorties de dust Taproot ≤ 1000 sats (~85% des sorties Taproot actuellement à cause des « retarded »)
• Toutes les sorties déjà envoyées

Cela permet de gagner un peu de temps pour mieux implémenter des optimisations telles que les transactions cut-through, les index spécifiques aux transactions Silent Payment dans Bitcoin Core, et d’autres à venir.

Structure de Données d’un portefeuille Silent Payment (exemple)

Pour un portefeuille Silent Payement, la structure de données doit inclure plusieurs éléments essentiels pour gérer les transactions et garantir la confidentialité. Voici à quoi pourrait ressembler cette structure :

Informations Générales :

• Identifiant du Portefeuille : Un identifiant unique pour le portefeuille.
• Réseau : Indique si le portefeuille est sur le réseau principal (mainnet) ou un réseau de test (testnet).

Clés Cryptographiques :

• Clé de Scan (Scan Key) : Clé privée utilisée pour scanner la blockchain et trouver les transactions destinées à ce portefeuille.
• Clé de Dépense (Spend Key) : Clé privée utilisée pour dépenser les fonds reçus.
• Clé de Scan Publique : Clé publique associée à la clé de scan privée.
• Clé de Dépense Publique : Clé publique associée à la clé de dépense privée.

Sorties Possédées (Owned Outputs) :

• Outpoint : Référence à la sortie (transaction ID et index).
• Bloc de Hauteur : Hauteur du bloc dans lequel la sortie a été confirmée.
• Valeur Tweaked (Tweak Value) : Valeur de réglage utilisée pour générer l’adresse unique.
• Montant : Montant des fonds dans la sortie.
• Script : Script associé à la sortie.
• Label : Étiquette facultative pour identifier la sortie depuis son destinataires avec une empreinte unique
• Statut de Dépense : Statut indiquant si la sortie est dépensée, non dépensée, ou minée.

Liste de Sorties (Output List) :

• Empreinte du Portefeuille (Wallet Fingerprint) : Empreinte unique du portefeuille dérivée des clés de scan et de dépense.
• Anniversaire : Hauteur du bloc à laquelle le portefeuille a été créé ou initialisé.
• Dernier Scan : Hauteur du bloc jusqu’où le portefeuille a scanné pour trouver des transactions.
• Sorties : Une collection de sorties possédées, indexée par outpoint.

Transactions :

• ID de Transaction de Dépense : ID des transactions qui ont dépensé les sorties de ce portefeuille.
• Bloc de Confirmation : Bloc dans lequel les transactions ont été confirmées.

Quelques questions sur la suite

• Quel stockage de la clé de dépense et de la clé de scan sur des portefeuilles matériels ? La clé de scan côté logiciel ?
• Quel format d’export des portefeuilles ? Avec quelles informations pour éviter ou réduire les rescans de tous les blocs depuis une date de création du portefeuille ?
• Quelle gestion des labels ? Quelle UX ? Quel export ?
• Faut-il extraire les secrets pour pouvoir les réutiliser ? Faut-il les exporter avec le portefeuille ?
• Quelle est la pertinence des wallet descriptors si toutes les adresses sont des adresses Silent Payments et que tous les scripts sont des scripts Taproot afin de masquer les formats et informations réelles ? Le format des wallet descriptors est-il suffisamment sémantique pour intégrer les autres informations systématiquement nécessaires lors des exports ?
• Adapter les protocoles de relais de bloc et de transactions à scanner pour qu’ils remontent des informations utiles à Silent Payments en plus des blocs.
• Fournir des protocoles compatibles avec les navigateurs pour la réception des blocs et transactions à scanner (web sockets ?).

Quelques premiers cas d’usages pour le paiement

• Protection de la confidentialité des dons
• Pourboires sans s’exposer à des risques pour sa sécurité
• Partage de son adresse entre amis et pour les échanges récurrents afin de faciliter les transactions futures

Quelques avantages pratiques

• Automatisation « normalisée » de la génération d’adresses uniques
• Supprimer le besoin de gérer les mouvements par adresses (car toutes uniques) et évoluer vers la gestion des « labels » regroupant automatiquement dans le portefeuille par destinataires. C’est une cardinalité plus proche des usages que les adresses.
• Simplification des formats d’adresses et de transactions, avec tous les Silent Payments et tous les Taproot en cible (si c’est le choix principalement adopté, chacun choisira notamment par rapport aux Paynyms).
• Protection de l’émetteur et du récepteur grâce aux adresses uniques pour les deux.
• Évolution impactant faiblement les infrastructures, car c’est au niveau des portefeuilles : scan des blocs et deux clés à gérer, mais n’impliquant pas de backend spécifiques (sauf de façon temporaire pour les blocs avant d’adapter les nœuds).

Quelques premiers cas d’usages complémentaires hors portefeuilles

• Utilisations on-chain du secret partagé : flags dans les transactions
• Utilisations tierces du secret partagé : messagerie
• Identité publique partageable et très peu traçable
• Identité publique dans des annuaires « anonymes » de contrats ou de communautés avec des adresses de 2FA et utilisation dans un portefeuille 2FA pour réduire le lien entre les deux facteurs sans trop diversifier les moyens (plus simple si la même application

Questions

Envoyez moi vos questions NicolasCantuBk sur Twitter/X ou sur LinkedIn, elles seront consolidées ici.

• Est-ce que cela casse le suivi des nouveaux UTXOs, et peut-on donc consolider ceux qu’on veut, du moment qu’on fait un payjoin/stowaway ?

Silent Payments permet d’éviter la réutilisation des adresses tout en réduisant le nombre d’interactions nécessaires pour indiquer qu’un paiement a été envoyé ou pour en partager des éléments. On peut donner son adresse Silent Payments une fois, ou la publier, et tout le monde peut envoyer des fonds sans jamais réutiliser une adresse. Il n’est pas possible pour un observateur extérieur à la transaction (ni le receveur, ni l’envoyeur) de déduire à partir d’une adresse Silent Payments quelles adresses appartiennent à celui qui prétend la détenir. Cela ne retire pas les problèmes de la consolidation pour l’analyse de chaîne, qui se base beaucoup sur l’heuristique « tous les inputs d’une transaction sont contrôlés par la même personne ». La consolidation des fonds depuis plusieurs adresses de réception dérivées de la même adresse Silent Payments permet de savoir que ces entrées ont le même propriétaire. Il n’est cependant pas possible d’en déduire l’adresse Silent Payments originelle. BIP 352 a été conçu pour être compatible avec des protocoles de dépense CoinJoin, même si ce n’est pas encore appliqué. Néanmoins, il est possible de brouiller les heuristiques en envoyant des montants différents sur des adresses différentes (mais de la même adresse Silent Payments), possiblement combiné à du CoinJoin, ce qui donne des entrées différentes et des sorties indistinctes.

Ressources et références

Super spaces Twitter/X sur le sujet :

Lexique

Paynyms – BIP 47

Paynyms sont une fonctionnalité introduite par BIP 47, qui permet de créer des codes de paiement réutilisables pour les portefeuilles Bitcoin. Ces codes facilitent la réception de paiements sans nécessiter de réutiliser les adresses Bitcoin, ce qui protège la confidentialité des utilisateurs.

Fonctionnement:

• Code de paiement réutilisable: Un Paynym est un identifiant unique qui dérive des clés publiques du destinataire.
• Transactions de notification: Pour initier un paiement, une transaction de notification spéciale est envoyée pour établir un canal de paiement, après quoi l’expéditeur peut générer des adresses pour le destinataire sans autre interaction.
• Avantages: Évite la réutilisation des adresses et facilite les paiements récurrents de manière confidentielle.
• Limites : La nécessité d’une transaction de notification, pour initier une relation de paiement avec un nouveau destinataire, l’expéditeur doit envoyer une transaction de notification. Cette transaction est nécessaire pour établir un canal de paiement et permettre à l’expéditeur de générer des adresses pour le destinataire sans autre interaction. Cela ajoute une étape supplémentaire et des frais de transaction initiaux, ce qui peut être perçu comme une complexité et un coût supplémentaires. La transaction de notification contient des métadonnées spécifiques qui peuvent être observées sur la blockchain. Bien que ces métadonnées ne révèlent pas directement l’identité des utilisateurs, elles peuvent être utilisées pour identifier des schémas de comportement ou des relations de paiement entre les parties. Cela peut réduire la confidentialité, car les observateurs peuvent potentiellement lier des transactions de notification à des adresses spécifiques. L’implémentation de BIP 47 dans les portefeuilles Bitcoin nécessite une gestion supplémentaire pour les transactions de notification et la génération des adresses dérivées. Tous les portefeuilles ne supportent pas encore BIP 47, ce qui limite l’interopérabilité. La complexité accrue peut rendre l’adoption plus difficile pour les développeurs et les utilisateurs finaux. Actuellement, l’adoption de BIP 47 n’est pas universelle et se heurte des débats sur l’utilisation des OP_RETURN qui freine son adoption dans les portefeuilles de référence.

BIP 32 – Portefeuilles déterministes hiérarchiques

BIP 32 propose un standard pour les portefeuilles Bitcoin déterministes hiérarchiques (HD wallets), qui permet de dériver plusieurs clés à partir d’une seule clé maître (seed).

Fonctionnement:

• Clé maître: Une clé racine est générée à partir d’une seed aléatoire.
• Arborescence de clés: Des clés enfants sont dérivées de la clé maître de manière hiérarchique.
• xpub et xprv: Le portefeuille peut exporter des clés publiques étendues (xpub) ou privées étendues (xprv), permettant de générer des adresses sans exposer les clés privées.
• Avantages: Simplifie la gestion des clés, améliore la sécurité et la confidentialité, et permet la sauvegarde unique pour l’ensemble du portefeuille.
• Limites des xpub : Une fois qu’une xpub est exposée, elle peut être utilisée pour générer toutes les adresses publiques futures de ce chemin spécifique. Si cette xpub tombe entre de mauvaises mains, l’exposition des futures adresses compromet la confidentialité. Toute personne ayant accès à une xpub peut surveiller toutes les transactions entrantes associées à cette clé. Cela signifie que la confidentialité des transactions est compromise si la xpub est partagée (alors que dans Silent Payment la clé privée de scan et la clé privée de spend sont différentes). D’ailleurs les xpubs ne permettent pas de dériver des clés privées, ce qui signifie qu’elles ne peuvent pas être utilisées pour dépenser des fonds. Cela limite leur utilisation à des scénarios de lecture seule ou de réception de fonds uniquement. Les portefeuilles dérivés d’une xpub spécifique sont fragmentés et gérés séparément des portefeuilles dérivés d’autres xpubs. Cette fragmentation peut compliquer la gestion des fonds et des transactions. Si une xpub est compromise, même si les fonds ne peuvent pas être dépensés, la compromission des informations de réception peut encore causer des problèmes de confidentialité et de suivi. La sauvegarde et la récupération des xpubs peuvent être complexes, surtout lorsqu’il y a plusieurs chemins de dérivation et plusieurs comptes impliqués.

Courbes elliptiques avec clés privées et publiques

Les courbes elliptiques sont utilisées dans la cryptographie pour créer des paires de clés (privées et publiques) sécurisées.

Fonctionnement :

• Clé privée: Un grand nombre aléatoire utilisé pour générer une clé publique.
• Clé publique: Un point sur la courbe elliptique calculé à partir de la clé privée, utilisé pour chiffrer des données ou vérifier des signatures.
• Équation: Les courbes elliptiques utilisées en cryptographie suivent l’équation y2=x3+ax+by^2 = x^3 + ax + by2=x3+ax+b.

Diffie-Hellman elliptique (ECDH)

ECDH (Elliptic Curve Diffie-Hellman) est un protocole cryptographique permettant à deux parties de générer un secret partagé en utilisant leurs clés publiques et privées respectives.

Fonctionnement :

• Clés publiques et privées: Chaque partie génère une clé publique à partir de sa clé privée.
• Secret partagé: Le secret est calculé en combinant la clé privée de l’une des parties avec la clé publique de l’autre, grâce à une opération sur la courbe elliptique.
• Sécurité: Le secret partagé peut être utilisé pour chiffrer des communications entre les parties sans qu’un tiers puisse l’intercepter.

Agrégation des clés

L’agrégation des clés est un processus permettant de combiner plusieurs clés publiques en une seule, simplifiant ainsi les signatures et les vérifications.

Fonctionnement :

• Clés publiques agrégées : Plusieurs clés publiques sont combinées pour former une clé publique unique.
• Signatures agrégées : Une seule signature peut être utilisée pour vérifier une transaction impliquant plusieurs parties, ce qui améliore l’efficacité et la confidentialité.
• Utilisations : Utilisée dans les transactions collaboratives et les protocoles de confidentialité comme MuSig.

Stealth Addresses

Les stealth addresses permettent de recevoir des paiements de manière confidentielle en générant des adresses uniques pour chaque transaction.

Fonctionnement :

• Adresse furtive : Une adresse publique générée pour chaque paiement, basée sur un secret partagé entre l’expéditeur et le destinataire.
• Scan de la blockchain : Le destinataire scanne la blockchain pour trouver les transactions destinées à ses adresses furtives.
• Avantages : Améliore la confidentialité en empêchant les observateurs de lier les transactions à une adresse publique unique.

MuSig

MuSig est un schéma de signature multi-signatures amélioré pour les courbes elliptiques, qui permet à plusieurs parties de signer une transaction de manière plus efficace et sécurisée.

Fonctionnement :

• Agrégation des clés : Les clés publiques des signataires sont combinées en une clé publique agrégée.
• Signature unique : Une seule signature est générée, représentant l’accord de tous les signataires.
• Avantages : Réduit la taille des signatures et améliore la confidentialité des transactions multi-signatures.

FROST

FROST (Flexible Round-Optimized Schnorr Threshold signatures) est un protocole pour les signatures de seuil, offrant une flexibilité et une efficacité accrues par rapport aux méthodes traditionnelles.

Fonctionnement :

• Seuil de signatures : Un sous-ensemble des signataires peut générer une signature valide, sans nécessiter la participation de tous les signataires.
• Optimisation des tours : Réduit le nombre de tours de communication nécessaires pour générer une signature.
• Avantages : Améliore l’efficacité et la résilience des systèmes de signature distribués.

Article publié originellement le 31 mai 2024 sur linkedin.

A propos de l’auteur

Cofondateur de 4NK, Nicolas Cantu est entrepreneur, conférencier, enseignant et expert de Bitcoin de longue date.