Nous sommes fiers d’annoncer que le BitBox02 est le premier hardware wallet capable d’effectuer des paiements silencieux Bitcoin en toute sécurité. Dans cette série d’articles de blog, nous voulons vous montrer comment fonctionnent les paiements silencieux, et ce que fait le BitBox02 en coulisses pour garantir que ces paiements soient effectués de manière sécurisée.

La prise en charge de l’envoi vers des adresses de paiement silencieux sera mise à la disposition de tous les utilisateurs du BitBox02 dans une prochaine mise à jour.

  • La partie I explique le fonctionnement général des paiements silencieux
  • La partie II montrera ce que fait votre BitBox02 en coulisses afin de prendre en charge les paiements silencieux de manière sécurisée

Les paiements silencieux constituent une BIP (Bitcoin Improvement Proposal) pour un nouveau format d’adresse Bitcoin. Leur principal avantage est qu’il s’agit d’une adresse statique. Cela supprime la nécessité de gérer plusieurs adresses, tout en préservant la confidentialité. Si vous souhaitez en apprendre davantage sur les bases de ce concept, consultez notre article précédent sur les codes de paiement réutilisables.

Aujourd’hui, pour préserver la confidentialité, un destinataire doit interagir avec un expéditeur afin de lui fournir une nouvelle adresse pour chaque transaction. Cela entraîne une mauvaise expérience utilisateur ou des difficultés opérationnelles.

Par exemple :

  • Retrait depuis une plateforme d’échange : pour chaque retrait, vous devez obtenir une nouvelle adresse de réception inutilisée dans le BitBoxApp, enregistrer cette nouvelle adresse sur la plateforme d’échange et vérifier qu’il s’agit bien de la bonne adresse sur la BitBox et sur un second appareil
  • Dépôt sur une plateforme d’échange : pour chaque dépôt, vous devez créer une nouvelle adresse de dépôt sur la plateforme d’échange et la vérifier sur un second appareil et sur votre BitBox avant d’envoyer les fonds
  • Collecte de dons : vous devez configurer et exploiter un serveur comme BTCPay Server pour créer de nouvelles adresses pour chaque donateur

De nombreux services et utilisateurs Bitcoin évitent les complexités ci-dessus en réutilisant une seule adresse, au détriment de leur confidentialité, car toutes les transactions liées à cette adresse peuvent être facilement identifiées et analysées.

Les paiements silencieux visent à résoudre ces difficultés. Ils utilisent des adresses statiques destinées à être réutilisées, tandis que les transactions qui leur sont envoyées ne peuvent être identifiées que par l’expéditeur et le destinataire. Les associations caritatives pourraient publier publiquement leur adresse de don sur leur site web sans que personne ne puisse savoir qui a donné, ni combien. Les plateformes d’échange pourraient enregistrer votre unique adresse de paiement silencieux pour tous les retraits.

Les transactions aujourd’hui

Une transaction Bitcoin se compose d’entrées et de sorties.

Les sorties créent de nouveaux UTXO (unspent transaction outputs), et les entrées dépensent des UTXO existants. Si vous souhaitez en savoir plus sur les UTXO, consultez notre article de blog sur le sujet.

Le plus souvent, un UTXO est verrouillé par une seule clé publique, et dépensé en fournissant une signature créée avec la clé privée correspondante. Lorsque vous envoyez des bitcoins vers une adresse, cette adresse encode traditionnellement une clé publique (ou le hachage d’une clé publique).

Les paiements silencieux utilisent des techniques cryptographiques intéressantes pour dériver une nouvelle clé publique inutilisée pour chaque transaction envoyée vers une adresse de paiement silencieux. Construisons maintenant les bases et l’intuition nécessaires pour comprendre comment cela fonctionne. Ce qui suit est une description simplifiée et de haut niveau du fonctionnement des paiements silencieux. Pour tous les détails, veuillez consulter la proposition officielle.

Mini introduction : clés privées, clés publiques

Une clé privée est simplement un grand nombre, suffisamment grand pour ne pas pouvoir être deviné, par exemple :

92193805913277071008055984303319191614197341949664602874511898854633635443214

Pour chaque clé privée, il existe une clé publique correspondante. Connaître uniquement une clé publique ne révèle aucune information sur sa clé privée.

Techniquement, les clés publiques font partie d’un groupe mathématique dans lequel l’addition a une signification particulière. Si vous souhaitez en savoir plus à ce sujet, vous trouverez une excellente introduction dans la série d’articles « Elliptic Curve Cryptography: a gentle introduction ».

La formule pour dériver une clé publique à partir d’une clé privée est la suivante :

PublicKey = privateKey×G,

où G est une valeur prédéfinie appelée générateur. Le générateur est une clé publique spéciale. Toutes les autres clés publiques peuvent être générées à partir de lui par addition.

Par exemple, si votre clé privée est 2, votre clé publique est 2×G = G + G. Si votre clé privée est 3, votre clé publique est 3×G = G + G + G, et ainsi de suite. Bien entendu, dans la pratique, votre clé privée serait un grand nombre impossible à deviner, comme dans l’exemple ci-dessus.

À part le fait que la division soit impossible ici (sinon vous pourriez calculer la clé privée à partir de la clé publique !), la plupart des mathématiques habituelles fonctionnent de la même manière. Des règles familières comme la distributivité s’appliquent :

(a + b)×G = a×G + b×G

Dans la suite de cet article, nous utilisons des lettres minuscules pour les clés privées et des lettres majuscules pour les clés publiques. Par exemple : a×G = A.

Diffie-Hellman sur courbe elliptique

Elliptic-Curve Diffie-Hellman (ECDH) est un protocole simple permettant de créer un secret partagé entre deux parties, Alice et Bob.

Supposons qu’Alice veuille effectuer une transaction vers Bob.

  • Alice possède une paire clé privée / clé publique : a×G = A.
  • Bob possède une paire clé privée / clé publique : b×G = B.

Ils peuvent créer un secret que seuls eux connaissent sans communiquer autre chose que leurs clés publiques.

  • Alice calcule le secret partagé comme suit : S = a×B.
  • Bob calcule le secret partagé comme suit : S = b×A.

Vous pouvez voir que les deux valeurs sont identiques en remplaçant B = b×G et A = a×G :

S = a×B = a×(b×G) = a×b×G = b×a×G = b×(a×G) = b×A = S.

S=(a×b)×G est techniquement la clé publique correspondant à la clé privée a×b et pourrait être utilisée dans une sortie de transaction pour y envoyer des bitcoins, mais elle ne pourrait alors être dépensée qu’en combinant les clés privées d’Alice et de Bob.

Pour éviter de partager des clés privées, on peut toutefois l’interpréter comme une nouvelle clé privée en la hachant :

s = hash(S). Les fonds envoyés à l’adresse de paiement silencieux pourraient alors être verrouillés par la clé publique P = hash(S)×G = hash(a×B)×G = hash(b×A)×G.

Les fonds verrouillés par cette clé publique resteraient dépensables soit par l’expéditrice Alice (à l’aide de sa clé privée a), soit par le destinataire Bob (à l’aide de sa clé privée b). Comment verrouiller les fonds pour que seul Bob puisse les dépenser ? Voyons cela.

Paiements silencieux

Une adresse de paiement silencieux commence par le préfixe sp1 (et non par le préfixe habituel bc1) et ressemble par exemple à ceci :

sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv

Elle est assez longue, car elle encode non pas une mais deux clés publiques du destinataire : une clé publique B_scan pour le scan, et une clé publique B_spend pour la dépense. La clé publique supplémentaire est utilisée pour verrouiller les fonds de manière à ce que seul Bob puisse les dépenser.

Au lieu d’utiliser la clé publique P = hash(S)×G pour verrouiller les fonds, Alice ajoute la deuxième clé publique de Bob : P = B_spend + hash(S)×G. Elle calcule le secret partagé S en utilisant la clé publique de scan de Bob et sa clé privée : S=a×B_scan.

Alice peut créer cette clé publique P parce qu’elle connaît B_spend et B_scan à partir de l’adresse de paiement silencieux de Bob, et qu’elle connaît sa clé privée a.

La clé publique P ainsi obtenue est ajoutée à la transaction sous la forme d’une sortie Taproot.

Seul Bob peut dépenser ces fonds en utilisant ses deux propres clés privées b_spend et b_scan. Pour dépenser les fonds, il faut connaître la clé privée p de la clé publique P.

P = B_spend + hash(S)×G

Remplaçons B_spend = b_spend×G :

P = b_spend×G + hash(S)×G

Par la distributivité (a + b)×G = a×G + b×G, cela équivaut à :

P = (b_spend + hash(S))×G

La clé privée résultante permettant à Bob de dépenser les fonds est donc :

p = b_spend + hash(S).

Bob peut calculer le hachage du secret partagé S en utilisant sa clé privée de scan : hash(S)=hash(b_scan×A), puis produire la clé privée finale en y ajoutant b_spend.

Quelle clé privée Alice utilise-t-elle ? Comment Bob connaît-il sa clé publique ?

Alice, qui veut envoyer des fonds à Bob, connaît les clés publiques de Bob puisqu’elles sont encodées dans l’adresse de paiement silencieux de Bob.

Mais qu’en est-il des clés d’Alice ? Comment Bob connaît-il la clé publique d’Alice pour recréer le secret partagé, ce qui lui permet de détecter les paiements envoyés à son adresse de paiement silencieux et de dépenser les fonds ? Il serait peu pratique que le destinataire doive interagir avec chaque expéditeur pour recevoir ses clés publiques. La solution est plutôt élégante : toutes les clés pertinentes sont directement rattachées à la transaction elle-même !

Alice dépense ses propres UTXO dans une transaction vers Bob, et ceux-ci sont déjà verrouillés par une paire clé privée / clé publique. Elle a de toute façon besoin de ses clés privées pour dépenser ses fonds, alors pourquoi ne pas les utiliser aussi pour créer le secret partagé ?

Alice peut calculer le secret partagé utilisé dans le paiement silencieux en s’appuyant sur les clés privées de ses UTXO existants qu’elle utilise comme entrées dans la transaction.

Bob peut calculer le secret partagé en utilisant les clés publiques d’Alice, qui sont jointes aux entrées de la transaction.

Une transaction peut dépenser plusieurs entrées à la fois. Alice utilise donc une clé privée combinée, qui est la somme des clés privées de toutes les entrées :

a = a_1 + a_2 + …

Et Bob utilise la clé publique combinée d’Alice en additionnant les clés publiques des entrées de la transaction :

A = A_1 + A_2 + …

La somme des clés privées est la clé privée de la somme des clés publiques, encore une fois grâce à la distributivité :

A = (a_1 + a_2 + …)×G = a_1×G + a_2×G + … = A_1 + A_2 + …

Pour que les paiements silencieux fonctionnent, chaque entrée doit être associée à exactement une clé publique. Par conséquent, les seules entrées autorisées dans les transactions de paiement silencieux sont les suivantes : P2TR (dépenses par clé), P2WPKH, P2WPKH-P2SH et P2PKH, ou autrement dit les types de script à signature unique, qui sont actuellement les plus courants. Malheureusement, si Alice utilise un compte multisig natif (en mettant de côté MuSig2 et les autres schémas d’agrégation qui aboutissent à une seule clé publique) ou un autre compte reposant sur des scripts avancés, elle ne peut pas effectuer de paiements silencieux. Je considère que c’est un gros inconvénient des paiements silencieux et un obstacle majeur à leur adoption.

Garantir que les adresses ne sont pas réutilisées

L’objectif principal des paiements silencieux est d’éviter la réutilisation des adresses / clés publiques. Avec le schéma ci-dessus, la clé publique du destinataire est créée dynamiquement à partir des clés d’Alice dans les entrées de la transaction et de l’adresse de paiement silencieux de Bob. Cependant, si Alice elle-même ne faisait que réutiliser la même adresse, alors plusieurs transactions qu’elle enverrait à l’adresse de paiement silencieux de Bob pourraient finir par utiliser la même clé d’entrée et, par conséquent, produire la même clé publique de sortie.

Pour corriger cela, au lieu de calculer la clé de sortie comme ceci :

P = B_spend + hash(S)×G

Elle est calculée ainsi :

P = B_spend + hash(input_hash×S)×G

Où input_hash = hash(outpoint || A), c’est-à-dire le hachage de l’outpoint de l’une des entrées de la transaction. Un outpoint est un identifiant de transaction accompagné d’un index de sortie, qui identifie de manière unique un UTXO d’une transaction précédente. Comme les UTXO ne peuvent pas être dépensés deux fois dans Bitcoin, inclure le hachage d’un identifiant d’UTXO garantit l’obtention d’une clé publique de sortie unique, car aucun UTXO ne peut partager le même identifiant. A est inclus dans le hachage en raison d’une particularité technique décrite dans la BIP.

Dans une première version de la proposition, le hachage des entrées était calculé à partir de toutes les entrées de la transaction, triées par ordre lexicographique. Lors de ma relecture de cette version, j’ai signalé que cela posait problème pour les hardware wallets (cliquez sur « Show resolved » pour développer le fil) :

C’est problématique pour les hardware wallets. Leur mémoire est limitée et ils ne peuvent pas forcément charger tous les outpoints et les trier. Par conséquent, ils devraient imposer que les transactions aient déjà des entrées triées au moment de la signature, ce qui n’est pas souhaitable et entraînerait des problèmes de compatibilité. Peut-être qu’au lieu d’utiliser le hachage des outpoints triés, nous pourrions utiliser quelque chose comme : [...]

Dans la discussion qui a suivi, avec de nombreux participants, une solution a été trouvée qui satisfait les exigences et reste réalisable pour les hardware wallets : ne hacher qu’une seule entrée, la plus petite selon l’ordre lexicographique. Cette approche a été retenue dans la version finale de la BIP et nous a permis d’implémenter la prise en charge des paiements silencieux dans le BitBox02 sans friction.

Résumé

Nous avons introduit le concept des paiements silencieux, une Bitcoin Improvement Proposal pour un nouveau format d’adresse Bitcoin qui permet de réutiliser des adresses statiques tout en préservant la confidentialité. Nous avons couvert les bases des clés privées et des clés publiques, puis expliqué le processus de création d’un secret partagé au moyen de Diffie-Hellman sur courbe elliptique (ECDH) et la manière dont cela peut être utilisé pour verrouiller des fonds afin que seul le destinataire puisse les dépenser.

Dans le prochain volet, nous verrons comment les paiements silencieux changent le rôle des hardware wallets, et nous examinerons en détail ce que les hardware wallets doivent faire pour prendre en charge les paiements silencieux de manière sécurisée.

Vous n’avez pas encore de BitBox ?

Protéger vos cryptos ne doit pas être compliqué. Le hardware wallet BitBox02 stocke hors ligne les clés privées de vos cryptomonnaies. Vous pouvez ainsi gérer vos fonds en toute sécurité.

Le BitBox02 existe aussi en version Bitcoin-only, avec un firmware radicalement ciblé : moins de code signifie moins de surface d’attaque, ce qui améliore encore votre sécurité si vous stockez uniquement du Bitcoin.

Commandez le vôtre sur notre boutique !

Questions fréquentes (FAQ)

Que sont les paiements silencieux ? Les paiements silencieux sont une Bitcoin Improvement Proposal qui introduit un format d’adresse statique, permettant de réutiliser des adresses tout en préservant la confidentialité grâce à la dérivation d’une clé publique unique pour chaque transaction.

Pourquoi les paiements silencieux sont-ils utiles ? Les paiements silencieux simplifient le maintien de la confidentialité dans les transactions Bitcoin en supprimant la nécessité, pour les destinataires, de générer une nouvelle adresse pour chaque transaction. Cela améliore l’expérience utilisateur et l’efficacité opérationnelle.

Comment les paiements silencieux améliorent-ils la confidentialité ? Les paiements silencieux permettent aux destinataires d’utiliser des adresses statiques sans révéler les détails des transactions, car seuls l’expéditeur et le destinataire peuvent identifier les transactions spécifiques, ce qui préserve la confidentialité.

Quel rôle joue Diffie-Hellman sur courbe elliptique (ECDH) dans les paiements silencieux ? ECDH aide à générer un secret partagé entre l’expéditeur et le destinataire, qui est ensuite utilisé pour créer une clé publique unique pour chaque transaction, permettant des paiements sûrs et privés.

Puis-je réutiliser une adresse de paiement silencieux ? Oui, les adresses de paiement silencieux sont conçues pour être réutilisées. Chaque transaction génère automatiquement une clé publique unique. Ainsi, même si l’adresse reste statique, la confidentialité est préservée.

Que fait le BitBox02 pour prendre en charge les paiements silencieux ? Le BitBox02 effectue les opérations cryptographiques nécessaires en toute sécurité en coulisses, garantissant que les paiements silencieux sont réalisés de manière sûre, avec des clés publiques uniques pour chaque transaction. La prise en charge sera ajoutée dans une prochaine mise à jour.

Shift Crypto est une société privée basée à Zurich, en Suisse. Notre équipe de contributeurs Bitcoin, d’experts crypto et d’ingénieurs en sécurité conçoit des produits qui permettent à nos clients d’évoluer sereinement du niveau débutant jusqu’à la maîtrise de la gestion des cryptomonnaies. Le BitBox02, notre hardware wallet de deuxième génération, permet aux utilisateurs de stocker, protéger et utiliser Bitcoin et d’autres cryptomonnaies en toute simplicité, avec son logiciel compagnon, le BitBoxApp.

This post was translated with the help of AI