Bitcoin est l’une des percées les plus importantes de toute l’ère numérique en termes de transfert de valeur entre une personne et une autre. Il ne nécessite pas d’intermédiaires. Il est sécurisé par un quorum décentralisé de mineurs et validé par chaque participant du réseau qui le souhaite afin de garantir la validité des paiements individuels. L’architecture du système est conçue pour permettre à n’importe qui de n’importe où sur la planète de recevoir de l’argent de n’importe qui d’autre, peu importe où il se trouve. Le financement participatif, la charité, le financement de tout ce que vous voulez devient instantanément possible sans avoir besoin de la permission de qui que ce soit, sans traiter avec des gardiens, sans aucune bureaucratie. C’est une idée brillante en théorie, mais en réalité, elle souffre d’un énorme défaut : la confidentialité.
En tant que système de paiement push (personne n’est autorisé à vous « tirer » des paiements, vous devez les autoriser explicitement vous-même et les « pousser » à d’autres personnes), Bitcoin exige que l’expéditeur dispose des informations nécessaires pour définir la destination pour l’argent qu’ils envoient. Cela nécessite que le destinataire communique à l’expéditeur son adresse Bitcoin d’une manière ou d’une autre. Dans le cas d’essayer de collecter des fonds auprès du grand public, cela a des conséquences massives en termes de confidentialité ou de nécessité de maintenir une présence interactive constante en ligne. N’importe qui est tout à fait capable de simplement publier une seule adresse Bitcoin quelque part en ligne, et à partir de ce moment, quiconque souhaite envoyer de l’argent à cette personne peut simplement le faire, mais il n’y a aucune confidentialité à collecter des fonds de cette manière. Prenez simplement cette adresse et recherchez-la sur la blockchain, et vous ne pouvez pas seulement voir combien d’argent cette personne a été envoyée, mais vous pouvez voir l’empreinte sur la blockchain de tous ceux qui lui ont envoyé de l’argent. La personne qui tente de collecter des fonds et tous ceux qui lui ont fait un don n’ont aucune intimité ; tout est complètement ouvert et corrélé pour que le monde entier puisse le voir.
La seule alternative à la réutilisation des adresses sous la forme de l’affichage public d’une seule adresse statique nécessite l’exécution d’un serveur qui reste en ligne en permanence afin que les gens puissent demander une nouvelle adresse inutilisée chaque fois que quelqu’un de nouveau veut donner de l’argent. Bien qu’il ne semble pas être un problème d’avoir quelque chose en ligne tout le temps à l’ère numérique, cela a un coût et une complexité, surtout si quelqu’un essaie de l’exécuter lui-même à la maison sur son propre matériel. Et qu’en est-il des personnes qui n’ont qu’un appareil mobile ? Il est presque impossible de nos jours, avec les fonctionnalités actuelles du système d’exploitation, d’optimiser l’utilisation de la batterie pour que quelque chose fonctionne en arrière-plan toute la journée, et même si vous le pouvez, cela videra la batterie.
BIP47
Entrez BIP47 par Justus Ranvier. Le but de cette proposition est de permettre à quelqu’un de pouvoir publier suffisamment d’informations publiquement pour pouvoir recevoir des fonds de toute personne qui le souhaite, sans que ces informations publiques soient suffisantes pour (1) suivre le montant d’argent que la personne qui a publié il a reçu et (2) révéler au public toute information sur qui a envoyé des fonds à la personne qui les demande. L’idée de base est de prendre ces informations publiées publiquement (ou code de paiement) et, à partir de là, de combiner leur propre code de paiement pour générer un nouvel ensemble d’adresses pour lesquelles le destinataire peut construire les clés privées. Ce nouvel ensemble d’adresses est spécifique à la relation entre un seul expéditeur et le destinataire, chaque fois qu’un nouvel expéditeur utilise ce protocole pour envoyer de l’argent à un destinataire, il générera un nouvel ensemble d’adresses uniques pour les deux.
À un niveau élevé, le flux général suit en tant que tel : la personne qui souhaite recevoir de l’argent génère une nouvelle clé publique étendue à partir de son portefeuille HD dans un nouveau chemin de dérivation et la publie publiquement. Cette nouvelle clé publique fonctionne comme leur « code de paiement ». De là, quelqu’un voulant lui envoyer de l’argent prendra ce nouveau code de paiement, et il aura toutes les informations nécessaires afin de générer de nouvelles adresses pour envoyer de l’argent. Le problème est cependant que l’expéditeur doit communiquer ses propres informations de code de paiement au destinataire, sinon il ne sera pas en mesure de générer la clé privée nécessaire pour réellement dépenser les fonds qui lui sont envoyés. Cela nécessite une « transaction de notification » spéciale.
Supposons qu’Alice souhaite effectuer une transaction avec Bob en utilisant des codes de paiement. Alice sélectionne un UTXO à envoyer à l’adresse de notification de Bob, à partir de là, elle prend la clé privée associée à cet UTXO et la clé publique associée à l’adresse de notification de Bob. Elle les multiplie pour créer une clé secrète aveuglante. Avec cela, elle peut chiffrer son code de paiement et les encoder dans une sortie OP_RETURN. Cela signifie que Bob, prenant la clé privée de son adresse de notification et la clé publique de l’entrée dépensée d’Alice, est la seule personne qui peut décrypter et lire ces informations. Cela fonctionne car la multiplication de la clé privée d’Alice avec la clé publique de Bob produit la même valeur que la multiplication de la clé privée de Bob avec la clé publique d’Alice.
Alice et Bob peuvent désormais dériver un nouvel ensemble d’adresses dont seuls eux deux sont conscients, et Alice peut désormais envoyer n’importe quelle quantité de transactions à Bob en utilisant une nouvelle adresse à chaque fois sans qu’aucun observateur externe ne soit conscient du lien entre eux. Il existe une deuxième variante où, au lieu d’envoyer une sortie à la transaction de notification de Bob, Alice crée une sortie de modification à elle-même en utilisant un multisig 1 sur 2 où une clé est son adresse de modification et la seconde est l’identifiant de code de paiement de Bob. Une troisième variante utilise une sortie multisig 1 sur 3 pour coder les informations nécessaires au lieu de OP_RETURN. A part ça, les choses fonctionnent de la même manière.
Le seul inconvénient de BIP47 est la nécessité d’utiliser l’espace de bloc pour envoyer une transaction spéciale notifiant à un destinataire qu’il va recevoir de l’argent avant de le dépenser. Cela s’avère très inefficace pour les cas d’utilisation où quelqu’un essaie seulement d’envoyer un seul paiement. Il existe également un risque de nuire activement à la vie privée si l’UTXO utilisé pour la transaction de notification est connecté aux UTXO utilisés pour effectuer des paiements aux adresses BIP47 de quelqu’un. Il faut veiller à assurer l’isolement entre ces deux choses pour ne pas créer de corrélations qui pourraient être suivies sur la chaîne et la propriété associée des UTXO résultant de paiements différents.
Paiements silencieux
Les paiements silencieux sont la dernière idée de Ruben Somsen. Il résout efficacement le même problème que BIP47 sans avoir besoin d’une transaction de notification avec le compromis de devoir analyser plus de transactions pour détecter les paiements effectués au destinataire. L’idée est abstraitement à peu près la même : vous publiez une information publique, et à partir de là, un expéditeur est capable de construire une nouvelle adresse que seul le destinataire pourra reconstruire. La différence réside dans les détails de mise en œuvre.
Le destinataire publie une clé publique « silencieuse » dans un endroit accessible, puis l’expéditeur la prend et modifie cette clé publique en utilisant la clé privée d’une entrée qu’il va dépenser pour effectuer un paiement au destinataire. Cela se fait en multipliant la clé privée de l’expéditeur avec la clé publique silencieuse du destinataire, puis en ajoutant à nouveau cette clé publique silencieuse. Il en résulte une nouvelle adresse, que le destinataire peut récupérer en multipliant sa clé privée par la clé publique de l’expéditeur et en ajoutant sa clé publique silencieuse. C’est si simple.
Le gros inconvénient ici est que la prise en charge des clients légers est très difficile, car le récepteur doit analyser chaque transaction dans chaque bloc et calculer les combinaisons d’entrées ajustées à leur clé pour voir si cela correspond à une sortie dans une transaction. Pour un utilisateur de nœud complet, ce n’est pas une augmentation insupportable des coûts de validation, mais pour les portefeuilles légers sans leur propre nœud complet, cela devient très coûteux. Cela pourrait être encore optimisé en scannant simplement l’ensemble UTXO. Jonas Nick de Blockstream a effectué un test de référence sur un Intel i7, et il a constaté qu’il fallait environ trois heures et demie pour analyser l’ensemble et exécuter les calculs pour vérifier les adresses. Cela n’incluait pas le temps nécessaire pour rechercher la transaction qui a créé chaque UTXO pour trouver les clés publiques d’entrée nécessaires pour exécuter ce calcul. Cela n’a pas encore été évalué ou testé, de sorte que le coût et le temps restent une question ouverte.
Une autre optimisation qui pourrait être faite consiste à utiliser chaque entrée de la clé publique de la transaction d’envoi dans le cadre du réglage, ce qui réduirait le coût de la numérisation pour voir si vous avez reçu de l’argent en ne vous obligeant pas à numériser chaque entrée individuelle dans une transaction. et exécutez le calcul individuellement. Cela augmenterait cependant la complexité de le faire avec les transactions CoinJoin, car cela obligerait tous les autres participants à participer activement aux ajustements clés. Cela leur divulguerait également la sortie que vous payez dans l’implémentation naïve. Cependant, cela empêcherait le destinataire d’apprendre quelle entrée a été utilisée pour le payer, et en masquant cryptographiquement les informations partagées avec les autres participants au CoinJoin, cela les empêcherait d’apprendre quelle sortie est le paiement silencieux, atténuant ainsi tous les problèmes de confidentialité.
Il est également possible d’ajouter une clé de numérisation et de dépense dans le processus de dérivation afin que le destinataire puisse disposer d’une clé en ligne qui est tout ce qui est nécessaire pour détecter les paiements entrants, tout en conservant la clé nécessaire pour dépenser les pièces qu’il a reçues hors ligne et en chambre froide. Cela changerait la dérivation en multipliant la clé privée d’entrée de l’expéditeur avec la clé de numérisation, puis en ajoutant la clé nécessaire pour les dépenses. Cela permettrait une plus grande sécurité dans la réception des paiements, ne laissant que votre vie privée en danger si l’appareil du destinataire était compromis.
Une dernière chose importante à considérer est le potentiel de réutilisation des adresses du côté de l’expéditeur. Dans l’implémentation de base, si un expéditeur a plusieurs UTXO avec la même clé publique, la réutilisation de ceux à envoyer à la même personne avec un paiement silencieux entraînerait la même adresse silencieuse et constituerait une réutilisation d’adresse. Cela pourrait être évité en incluant le TXID et l’index d’entrée de l’entrée de transaction utilisée dans le schéma, qui pourraient être précalculés avant d’être envoyés aux clients légers pour ne pas leur créer une charge de calcul supplémentaire.
Dans l’ensemble, l’idée est une amélioration substantielle par rapport au BIP47 à tous égards, à l’exception des coûts de validation plus élevés pour que le destinataire recherche les fonds qui lui ont été envoyés. Il conserve la propriété de récupération déterministe, assure la non-liaison entre les différents paiements envoyés au destinataire et supprime la nécessité d’une transaction de notification avant que les paiements ne soient effectués. Encore une fois, Somsen a proposé une idée très solide pour un protocole qui pourrait être mis en œuvre pour améliorer l’utilité de Bitcoin.
Ceci est un article invité de Shinobi. Les opinions exprimées sont entièrement les leurs et ne reflètent pas nécessairement celles de BTC Inc ou Bitcoin Magazine.
