Pour qu'un actif constitue un moyen d'échange, il doit être fongible, ce qui signifie que ses unités doivent être facilement interchangeables, chacun ayant la même valeur. L’analyse de la blockchain de Bitcoin pourrait permettre à une entité de déclarer certains bitcoins comme « sales » et de les étiqueter comme étant inacceptables en tant que moyen de paiement en raison de leur historique de transactions. Les sociétés d’analyse de blockchain, qui tentent de retracer la provenance et la propriété des bitcoins, compromettent la confidentialité des utilisateurs et introduisent une possible discrimination nuisant au libre échange des bitcoins. Ainsi, si la confidentialité des transactions ne peut pas être préservée à la base, Bitcoin perd une partie de sa fongibilité.
Un groupe de travail communautaire s’est récemment fixé l’objectif d'améliorer la confidentialité des transactions Bitcoin basiques. Nous présentons un résumé des résultats du groupe pour fournir aux développeurs de wallet une approche commune pour se défendre contre les procédures heuristiques les plus courantes utilisées par les sociétés d'analyse de blockchain et ainsi améliorer la fongibilité de Bitcoin.
Le groupe espère initier une discussion au sein de la communauté et faire progresser les développements visant à fournir un moyen standardisé aux wallets et aux processeurs de paiement d'interagir de façon plus confidentielle.
Contrer les outils d'analyse de la blockchain
Dans un article publié en 2013, Meiklejohn et al. ont décrit l’heuristique clé utilisée pour relier les adresses dans la blockchain de Bitcoin. Ils ont observé que l’un des principes fondamentaux de l'analyse de la blockchain est de considérer que « les différentes clés publiques utilisées comme entrées d'une transaction sont contrôlées par le même utilisateur ».
La composition d’une transaction Bitcoin régulière constitue donc un point d’entrée pour les sociétés d’analyse souhaitant tracer une adresse et son propriétaire. C’est à ce principe que l’atelier s’est attelé.
Notons que pour invalider l’hypothèse « qu’un seul propriétaire possède les adresses entrantes », il n'est pas nécessaire que chaque transaction utilise une des solutions proposées. Pour rendre cette hypothèse invalide, il suffit simplement de s'assurer qu’un nombre significatif de transactions incluent des inputs de différents propriétaires. Comme il s’agit de la pierre angulaire de l’analyse de la blockchain, il n’est pas déraisonnable de penser que les bases même de ces analyses pourraient être sapées si une telle solution était couramment utilisée.
Cette approche précisait l’objectif du groupe :
Fournir un moyen de s’assurer que les transactions dont les entrées appartiennent à plusieurs parties sont suffisamment fréquentes pour que l’hypothèse « de la propriété commune des inputs » soient invalidée.
Identifier les besoins essentiels
Parmi les diverses propositions présentées, des problèmes similaires ont été identifiées. Sans rentrer dans le détail, on pourrait y répondre de façon appropriée avec une solution qui :
- Permette d’établir un processus interactif entre les pairs.
- Empêche ou réduise l’impact des attaques de « snooping » sur les UTXO (lorsqu’un expéditeur tente de connaître les UTXO d’un destinataire en faisant des demandes répétées et incomplètes).
- Réduise l'impact des « non-responsiveness attacks »
La proposition "Pay to EndPoint" (P2EP)
L’itération d’idées diverses a abouti à la proposition “Pay to EndPoint” (P2EP). Bien qu’elle comporte ses propres compromis, elle semble atteindre les objectifs fixés, à savoir : rendre l’hypothèse de la « propriété commune des inputs » invalide et répondre aux exigences relatives à l’interaction entre pairs avec un niveau convenable de résistance aux attaques.
Le principe de base de P2EP est que l'expéditeur et le destinataire contribuent tous deux à une transaction via des interactions coordonnées par un EndPoint présenté par le destinataire à l'aide d'un URI conforme à BIP 21.
Etape 1
Le destinataire (commerçant ou utilisateur final) génère un URI au format BIP 21 avec un paramètre supplémentaire spécifiant l’EndPoint P2EP. BIP 21 autorisant des variables qui ne sont pas comprises actuellement, cela ne rompt pas les implémentations des wallets existants. L’EndPoint ne doit pas nécessairement être une adresse .onion, mais simplement l'URI d'un EndPoint compatible.
Un exemple d'URI (adapté des exemples de BIP 21): bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?p2ep=3j4tau93wkc8mh32.onion
Etape 2
L'expéditeur initie une interaction avec le destinataire en confirmant que l’endpoint fourni est disponible. Si ce n’est pas le cas, la transaction est diffusée normalement et payée à l’adresse Bitcoin BIP 21 du destinataire. Si l’endpoint du destinataire est disponible, l'expéditeur lui fournit une transaction signée lui prouvant qu’il est propriétaire de l’UTXO.
Etape 3
Le destinataire envoie un certain nombre de transactions à l'expéditeur pour signature. Parmi ces transactions, une seule inclut un UTXO qui appartient réellement au destinataire, le reste peut être sélectionné dans le pool d'UTXO dépensables. Ces transactions peuvent ensuite être envoyées en série ou en parallèle à l'expéditeur. Les deux approches présentent des avantages et des inconvénients en matière de confidentialité et de rapidité d’interaction. Cette méthode actuelle reste ouverte à la discussion et à l’implémentation.
Séries : Pour chaque transaction envoyée, il y a une certaine probabilité pour que ce soit celle du destinataire. La probabilité dépend du nombre de transactions que le destinataire a sélectionnées et signées et de la manière dont la séquence a été rendue aléatoire. La série d’échanges prend fin lorsque l'expéditeur soumet au destinataire une transaction signée qui utilise son UTXO.
Parallèle : Toutes les transactions créées par le destinataire sont envoyées à l'expéditeur en même temps. L'expéditeur aura alors un ensemble de transactions, dont une seule est celle du destinataire. La probabilité que le destinataire identifie la bonne est proportionnelle au nombre de transactions sélectionnées et envoyées par le destinataire. L'expéditeur signe et retourne toutes les transactions à la fois.
Le nombre proposé de transactions envoyées par le destinataire en utilisant l’une ou l’autre méthode est actuellement de 100, ce qui représente un équilibre entre la confidentialité et la charge de transmission / traitement des données de part et d’autre de l’échange.
Notons qu’il est possible d’utiliser des Bulletproofs pour remplacer les méthodes d’échange d’UTXO mentionnées ci-dessus.
Etape 4
Dans les deux cas décrits ci-dessus, lorsque le destinataire obtient une transaction signée correspondant à son UTXO, il peut signer et diffuser la transaction, qui contiendra désormais les entrées de l'expéditeur et du destinataire.
Si le processus P2EP échoue pour une raison quelconque, la transaction est diffusée en tant que transaction normale.
Exemple de transaction P2EP
Si Alice veut payer à Bob 1 BTC :
- Alice inclut 3 BTC dans une transaction.
- Bob inclut 5 BTC dans la même transaction.
- Alice reçoit 2 BTC (d’elle-même).
- Bob reçoit 6 BTC (de lui-même, plus le paiement de 1 BTC d’Alice).
La transaction ci-dessus rompt l'heuristique de « propriété commune des inputs » et peut être interprétée de nombreuses manières. Cela peut, par exemple, être interprété comme signifiant que Alice paye à Bob 6 BTC, à partir d’un total de 8 BTC en utilisant des entrées de 3 BTC et 5 BTC, et qu’elle récupère les 2 BTC qui restent.
Avantages et inconvénients du P2EP
Avantages :
- Casse l'hypothèse de « propriété commune du portefeuille ». L’effet cumulatif d’une adoption même minimale améliore la confidentialité des transactions non-P2EP.
- Rompt l'analyse de la somme des sous-ensembles.
- La consommation de l’UTXO du destinataire peut aider à réduire le phénomène de « gonflement des UTXO ».
- Le destinataire peut utiliser P2EP pour consolider son set d’UTXO.
- Contrairement à une transaction CoinJoin traditionnelle dont les inputs sont tous de la même valeur, ce type de transaction n’a pas « d’empreinte digitale » évidente, dans la mesure où elle a la même apparence qu’une transaction normale.
- Les portefeuilles d'envoi peuvent être des portefeuilles légers.
- Les expéditeurs et les destinataires bénéficient d'une plus grande confidentialité.
Inconvénients:
- Le destinataire et l'expéditeur doivent être en ligne pour que le paiement soit traité comme une transaction P2EP.
- La nature interactive de P2EP retarde légèrement la diffusion de la transaction.
- Le destinataire doit utiliser un hot wallet pour pouvoir signer les transactions.
- Les frais peuvent être plus importants pour l'expéditeur en raison de l'augmentation de la taille de la transaction. Cela peut se compenser en négociant avec le destinataire s'il valorise la consolidation des UTXO.
- La durée du traitement par le wallet est plus longue que pour des transactions traditionnelles.
- Le destinataire doit avoir accès à un nœud complet.
Quelle est la prochaine étape pour “Pay to EndPoint” ?
Le P2EP en est à ses débuts, la communauté doit l’évaluer et proposer des amélioration avant qu'une proposition formelle puisse être faite.
Il est possible que l'idée puisse être étendue à d'autres formes de transactions, telles que le fractionnement de paiement ou la permutation de coins.