JoinMarket, ZeroLink et CoinJoin mélangent leurs bitcoins

4 février 2022 La redaction 255 Views

Lorsqu’ils entendent le mot « CoinJoin », les premières choses qui viennent à l’esprit de nombreux Bitcoiners relativement nouveaux sont probablement les suivants ZeroLink Les implémentations Wasabi Wallet et Samourai Wallet. Au cours des dernières années, ces deux projets ont rendu la protection de la vie privée en bitcoin quasi courante, en la rendant beaucoup plus simple et plus accessible.

Si vous êtes nouveau dans ce domaine, vous n’êtes peut-être pas au courant du fait que le projet Wasabi Wallet a été mis en œuvre par le gouvernement britannique. JoinMarket fournit des outils CoinJoin aux utilisateurs de bitcoins depuis 2015.

Transactions collaboratives L’idée d’interrompre les hypothèses de propriété commune a été lancée par le développeur de Bitcoin Greg Maxwell en janvier 2013, puis formalisée dans le concept de » transactions collaboratives « . CoinJoin en août de la même année.

L’idée est restée en suspens pendant deux ans avant que quelque chose ne soit publié pour la mettre en œuvre, et il y a une raison à cela : Un problème avec l’idée générale qui a conduit à des échecs avec les tentatives précédentes, telles que Dark Wallet par Amir Taaki, était d’attirer des liquidités. Le CoinJoin peut être un outil très utile, mais s’il n’y a personne désireux de faire du CoinJoin avec vous ou aucun moyen de les trouver s’ils sont prêts, il ne sert pas à grand chose.

Le problème était de savoir comment convaincre les gens de rejoindre ce pool initial pour aider à le transformer en un plus grand pool de liquidités et d’utilisateurs. La solution de JoinMarket était assez simple et pourtant brillante à l’époque : fournir un mécanisme de marché afin que les fournisseurs de liquidité cohérents puissent réellement gagner de l’argent pour fournir de la liquidité aux pools CoinJoin.

JoinMarket fonctionne autour de ce qui est effectivement une place de marché pilotée par un carnet d’ordres, composée à la fois de faiseurs et de preneurs de marché qui achètent et vendent des liquidités CoinJoin pour rendre anonyme leur activité sur la chaîne.

Les faiseurs de marché peuvent attendre le temps qu’il faut avec des offres ouvertes jusqu’à ce que les preneurs arrivent et cherchent à payer pour leurs services. Cela résout le problème de l’utilisateur de rester assis et d’attendre éternellement quelqu’un avec qui se mélanger. Les teneurs de marché, qui cherchent à réaliser des bénéfices, sont incités par les frais qu’ils facturent à être toujours en ligne en attendant les preneurs ; et les preneurs, qui recherchent la confidentialité, sont incités à payer ces frais. C’est un arrangement gagnant-gagnant pour tout le monde.

Dans son architecture, ainsi que dans son potentiel d’amélioration de la coordination, JoinMarket offre une version potentiellement plus décentralisée du mélange de pièces par rapport au plus connu ZeroLink. Voici comment.

Comment le mélange est coordonné : ZeroLink Vs. JoinMarket

L’architecture globale de ZeroLink, comparée à celle de JoinMarket, est très différente.

Dans le cas de Wasabi et Samourai, il y a un seul serveur coordinateur géré par le fabricant du portefeuille codé dans le portefeuille. Tous les utilisateurs participent au CoinJoin en contactant ce serveur central et en s' »inscrivant » pour attendre que suffisamment d’utilisateurs se soient inscrits pour construire le CoinJoin. Une fois que le nombre requis d’utilisateurs est présent et enregistré, le serveur coordinateur signe un justificatif aveugle représentant le droit de créer une sortie dans la transaction CoinJoin, et l’utilisateur se déconnecte et se reconnecte via une nouvelle connexion Tor pour enregistrer les sorties de la transaction.

Cela empêche le coordinateur de savoir quelles entrées correspondent à quelles sorties. Les utilisateurs paient une redevance au coordinateur pour son rôle dans la facilitation du CoinJoin. Dans ce modèle, il n’y a aucune incitation à fournir des liquidités, sauf pour les gains de confidentialité, et malgré les problèmes avec les tentatives passées comme Dark Wallet, cela semble fonctionner parfaitement pour Wasabi et Samourai.

JoinMarket, d’autre part, a un carnet d’ordres sur lequel les fabricants font de la publicité, permettant aux preneurs de choisir parmi les offres disponibles des fabricants (cela se fait actuellement par Internet Relay Chat [IRC]).

Les fabricants se connecteront au carnet d’ordres avec un identifiant unique, puis ils posteront une offre sur le carnet d’ordres contenant les informations suivantes : les frais que le fabricant facture pour le mélange avec les preneurs, le montant que le fabricant contribuera aux frais des mineurs, puis la valeur minimale et maximale de la dénomination dans laquelle ils feront des sorties en mélange. Ils affichent également un moyen pour les gens de se connecter directement à eux en privé.

Lorsque les preneurs veulent se joindre à CoinJoin, ils téléchargent le carnet d’ordres et leur client sélectionne les fabricants avec lesquels ils vont se mélanger en fonction de leurs paramètres. Après que le client ait sélectionné un fabricant, le preneur postera une clé publique temporaire pour le cryptage et commencera à communiquer avec le fabricant par le biais de messages cryptés sur IRC (il convient de noter qu’il est possible pour plusieurs preneurs d’être connectés à un seul fabricant en même temps). Si toutes les parties sont d’accord, elles signent la transaction, y compris les frais du preneur pour le fabricant, et la soumettent au réseau.

En raison de la façon dont cette coordination fonctionne, les fabricants apprennent les résultats des preneurs dans le processus de coordination de la construction de CoinJoin. Pour atténuer cela, JoinMarket a une fonction « tumble », où le client du preneur mélangera plusieurs fois avec différents fabricants jusqu’à atteindre le nombre de mélanges fixé. Cela garantit qu’aucun fabricant ne sera en mesure de dérouler l’historique complet des mélanges d’un seul preneur, car chaque fabricant le long de la « route du tumble » ne connaît que les connexions de cette seule transaction.

Ces différences ont beaucoup d’implications globales en termes d’architecture de conception pour JoinMarket, comme nous le verrons en examinant l’état actuel du projet ainsi que les plans futurs.

Comment les attaques de sybilles sont atténuées : ZeroLink Vs. JoinMarket

Les attaques sybiles – dans ce contexte, un utilisateur unique se faisant passer pour de nombreux utilisateurs afin de porter atteinte à la vie privée en créant une fausse « foule » dans laquelle les autres peuvent se cacher alors qu’ils constituent en réalité la « foule » entière – sont un problème fondamental de tout protocole de mélange sur Bitcoin. Si la foule entière est composée de vous et de l’attaquant Sybil, et de personne d’autre, l’attaquant connaît toutes vos pièces et vous n’avez gagné aucune confidentialité de son point de vue. En fin de compte, il n’y a pas de solution fondamentale à ce problème, tout ce que vous pouvez faire pour l’atténuer est d’augmenter le coût de l’attaque.

Dans le cas de ZeroLink, le problème est atténué par la facturation de frais par le coordinateur. Tant que le coût des frais des mineurs est plus élevé que le revenu des frais que le serveur du coordinateur collecte, même le coordinateur subit une perte nette en essayant d’attaquer ses propres utilisateurs.

Pour JoinMarket, la question est un peu plus compliquée. Vous devez protéger les preneurs, dans leur cas contre les fabricants qui attaquent le carnet d’ordres de manière à ce qu’un preneur ne se mélange qu’avec eux et révèle l’historique complet de leur mélange au fabricant malveillant. Mais il faut aussi protéger les preneurs contre les attaques des fabricants qui demandent des CoinJoins et se retirent ensuite du protocole après que le fabricant ait révélé ses résultats au preneur.

Cela permet au preneur malveillant de séparer les entrées de ce fabricant dans les transactions futures des preneurs avec lesquels ils se mélangent. En répétant cette opération plusieurs fois de suite contre le même fabricant, il pourrait désanonymiser les preneurs qui se sont mélangés avec lui.

Il y a deux mécanismes dans ce système pour offrir une défense appropriée pour chaque classe d’attaque : Le premier, pour traiter les preneurs espionnant les fabricants, est une preuve de l’équivalence du logarithme discret (défense numéro deux dans le document ce compte-rendu(également connu sous le nom de PoDLE).

L’idée de base est que pour une paire de clés privée/publique pour un UTXO Bitcoin, vous pouvez générer une deuxième clé publique différente correspondant à la clé privée, et créer une preuve à connaissance zéro (ZKP) montrant qu’elles partagent toutes deux la même clé privée. Après avoir fourni la deuxième clé et la preuve au fabricant, le preneur révèle la ou les premières clés publiques correspondant à la ou aux sorties qu’il veut mélanger.

Maintenant, cette configuration permet à un fabricant de publier la deuxième clé publique et ZKP à tous les autres fabricants sans doxxer les sorties réelles du preneur – de cette façon, si un preneur qui est coordonné avec le fabricant original essaie de réutiliser cette sortie pour espionner plusieurs fabricants en même temps, tous les autres fabricants verront que la première clé publique du preneur correspond à la deuxième clé publiée et ZKP. Ils refuseront alors de révéler leurs propres sorties au preneur malveillant. Cela augmente le coût des preneurs espionnant les sorties des fabricants en exigeant qu’un preneur ait des sorties uniques pour chaque fabricant qu’il espionne, au lieu d’être capable de réutiliser les mêmes sorties pour attaquer plusieurs fabricants.

Le deuxième mécanisme de défense consiste à protéger les preneurs contre les fabricants malveillants qui prétendent être de nombreux fabricants différents dans le carnet de commandes, permettant ainsi au fabricant malveillant de démêler le mélange de preneurs qui finissent par se mélanger uniquement avec l’attaquant.

Ce mécanisme est appelé un lien de fidélitéqui consiste essentiellement à prendre une grande quantité de bitcoins et à les verrouiller dans le temps. Les preneurs qui le font peuvent alors signer et publier des messages avec cette clé pour prouver leur contrôle sur les pièces verrouillées dans le temps. Les clients des preneurs, s’ils ont configuré leur client pour utiliser des obligations de fidélité, pondéreront alors leur sélection de fabricants à utiliser pour préférer ceux qui ont des montants plus élevés de valeur bloquée dans le temps dans des obligations de fidélité. Les obligations de fidélité sont pondérées par le carré du nombre de pièces bloquées, c’est-à-dire que si vous bloquez quatre bitcoins, la pondération sera de 16 ; cinq seront pondérés par 25 ; six seront pondérés par 36, etc.

Le raisonnement ici est que vous obtenez des avantages composés en tant que fabricant avec plus de pièces que vous verrouillez (vous êtes choisi par les clients preneurs plus souvent), donc si quelques fabricants honnêtes créent des obligations de fidélité très grandes, ils augmentent considérablement le coût pour les fabricants Sybiling qui devraient reproduire ce grand montant d’obligation de fidélité pour chacune de leurs fausses identités dans le carnet d’ordres. Par exemple, si trois fabricants honnêtes mettent chacun 10 bitcoins en obligations de fidélité, un attaquant devra dépenser 30 bitcoins pour avoir 50 % de chances d’être choisi, 60 bitcoins pour avoir 66 % de chances d’être choisi, etc.

Plus il y a de fabricants honnêtes qui utilisent des obligations de fidélité, plus le coût de l’attaque Sybil augmente pour les fabricants malveillants.

Comment le mécanisme de coordination de JoinMarket pourrait être mis à niveau

Dans le cas de ZeroLink, tout le monde se coordonne par le biais du serveur coordinateur centralisé – c’est une partie explicite de la conception du système et du modèle de confiance en termes de fiabilité. Si le coordinateur tombe en panne, personne ne peut faire de CoinJoin jusqu’à ce qu’il soit rétabli.

JoinMarket fonctionne sur un système de carnet d’ordres pour essayer d’éviter ce point central de défaillance, mais comme mentionné ci-dessus, il utilise actuellement IRC comme couche d’hébergement et de communication pour le carnet d’ordres. L’IRC est un point central de défaillance potentiel pour JoinMarket, tout comme le serveur de coordination l’est pour ZeroLink. En tant que projet construit autour de la coordination des CoinJoins d’une manière décentralisée, à long terme cette dépendance à l’IRC doit être remplacée par quelque chose de plus robuste.

L’une des propositions les plus développées est d’implémenter une sorte de serveur IRC. schéma de serveur de répertoire similaire à celui utilisé par le projet Tor. Dans le réseau Tor, les clients se connectent à un ensemble de serveurs gérés par les contributeurs de Tor qui leur envoient tous les nœuds du réseau Tor à travers lesquels ils peuvent construire des routes en oignon.

L’idée avec JoinMarket serait d’avoir un ensemble similaire de serveurs qui envoient aux clients tous les fabricants avec des offres ouvertes. Ces serveurs devraient être gérés par quelqu’un d’autre que les fabricants, parce que chaque fabricant serait incité à ne s’annoncer que sur son propre serveur d’annuaire pour collecter plus de frais. Il faudrait également qu’il soit difficile de rejoindre l’ensemble des serveurs d’annuaire, sinon des entités malveillantes pourraient en créer un grand nombre et attaquer par Sybil tous les utilisateurs qui se connectent uniquement aux serveurs malveillants.

Les obligations de fidélité pourraient potentiellement résoudre le problème de Sybil ici, ainsi que créer une dissuasion pour les fabricants d’essayer d’exécuter des serveurs de répertoire. En bloquant des pièces dans une obligation de fidélité pour un serveur d’annuaire, ils auraient moins de pièces à bloquer dans une obligation de fabricant, ce qui pourrait conduire à ce que moins de clients preneurs les sélectionnent pour des mélanges.

Il y a aussi une preuve de concept et proposition d’Adam Gibson pour intégrer c-lightning dans JoinMarket pour une utilisation comme couche de messagerie. Dans le contexte des serveurs d’annuaire, cela pourrait faciliter une méthode de monétisation pour eux en tant qu’entités séparées utilisant le réseau Lightning. Les serveurs d’annuaires pourraient faire payer aux fabricants de petites sommes via Lightning pour s’annoncer sur l’annuaire.

Comment le protocole de coordination JoinMarket pourrait se moderniser

Comme discuté ci-dessus, les fabricants apprennent les sorties des preneurs pendant les CoinJoins uniques, c’est pourquoi le mode tumbler existe, pour laisser les preneurs se mélanger à travers plusieurs fabricants et atténuer cela.

Il y a, cependant, une meilleure solution, au moins dans le cas où plusieurs preneurs parlent à un seul fabricant en même temps, et ils peuvent se coordonner en parlant directement les uns aux autres au lieu de passer uniquement par le fabricant (s’il n’y a qu’un seul preneur qui parle à un fabricant, cela n’aidera pas parce que le fabricant sait que chaque sortie qui n’est pas la sienne appartient au preneur). CoinShuffle est un protocole pour faire effectivement ce que les références aveugles accomplissent dans ZeroLink, pour garder les choses privées du coordinateur, mais d’une manière décentralisée pour un groupe sans coordinateur central.

Imaginez que vous avez Alice, Bob et Charlie, qui veulent tous faire un CoinJoin entre eux (ils se sont déjà mis d’accord sur la dénomination des sorties du CoinJoin), et tous les trois génèrent une clé publique temporaire pour chiffrer les messages.

Charlie donne sa clé publique à Bob, puis Bob donne à Alice sa propre clé publique ainsi que celle de Charlie. Nous sommes donc dans une situation où Alice possède les clés publiques de Bob et de Charlie, Bob possède la clé publique de Charlie, et Charlie ne possède que la sienne.

Alice prend l’adresse à laquelle elle veut envoyer son message et le crypte avec la clé de Charlie, mais prend ensuite ce message crypté et le crypte avec la clé publique de Bob, en l’imbriquant comme des poupées russes. Elle transmet ensuite ce message à Bob, qui décrypte sa couche pour découvrir un message crypté destiné à Charlie qu’il ne peut pas ouvrir. Bob prend alors l’adresse à laquelle il veut que son message soit envoyé, et le crypte avec la clé de Charlie. Il transmet les deux messages à Charlie. Charlie déchiffre alors les deux messages et trouve les adresses auxquelles Alice et Bob veulent envoyer leurs sorties, mais il ne sait pas quelle adresse appartient à qui (et rappelez-vous, ni Alice ni Bob n’ont appris les adresses des autres).

Charlie construit et signe alors le CoinJoin, le passe à Alice et Bob pour qu’ils le signent, et il est soumis au réseau. Tous les participants à ce processus savent que leur sortie a été construite correctement, mais ils ne savent pas à qui appartient chacune des deux autres adresses. Ce processus peut être étendu à des groupes beaucoup plus importants, et si les preneurs pouvaient communiquer directement entre eux avant d’approcher les fabricants, ce protocole pourrait être utilisé pour protéger la vie privée des preneurs contre les fabricants individuels sans avoir à faire tourner les pièces de monnaie plusieurs fois avec différentes parties.

Comment la structure de transaction de JoinMarket pourrait être améliorée

La plus grande similitude entre ZeroLink et JoinMarket est le recours à des produits dénommés similaires pour créer une ambiguïté sur les entrées et les sorties d’une transaction.

Alors que JoinMarket utilise des montants arbitraires par opposition aux montants prédéfinis dans ZeroLink, dans le cadre d’une seule transaction CoinJoin, toutes les dénominations de mélange doivent être les mêmes.

CoinjoinXT est une proposition de Gibson visant à supprimer la nécessité de s’appuyer sur ce principe de manière aussi stricte (ZeroLink pourrait également l’appliquer). L’idée de base est de tirer parti de ECDSA Multiparty Computation, ou MuSig maintenant que Taproot est activé, et créer une chaîne de transactions pré-signées en utilisant des adresses multisig qui ressemblent à des adresses normales à signature unique.

Lorsque quelqu’un observe la blockchain, deux grandes suppositions sont souvent faites : premièrement, que toutes les entrées d’une transaction appartiennent à une seule personne (la grande supposition que les CoinJoins brisent) ; et deuxièmement, qu’un paiement signifie que le contrôle des fonds a été transféré.

Alors, que se passerait-il si plusieurs parties collaboraient pour verrouiller tous leurs fonds dans une adresse multi-sig qui n’en a pas l’air, et pré-signaient une longue chaîne de transactions qui ressemble à une personne dépensant lentement de l’argent au fil du temps, mais qui en réalité ne fait que retirer de l’argent et le rendre aux propriétaires originaux par petits fragments ?

Et si certaines de ces sorties de paiement étaient en fait des canaux privés Lightning entre deux des participants de CoinjoinXT pour s’assurer qu’un observateur ne puisse pas suivre la chaîne de paiement et rassembler les montants à un moment donné dans le futur ?

Cela pourrait ouvrir une toute nouvelle porte en termes de flexibilité pour les types de CoinJoins dans lesquels les gens s’engagent, et les degrés de confidentialité qu’ils créent. Si un CoinJoin normal consiste à crier ouvertement à la salle « Je vais partir et disparaître maintenant ! », CoinjoinXT pourrait être l’équivalent d’une sortie discrète de la fête sans être remarqué.

L’avenir décentralisé

Dans l’ensemble, JoinMarket a honnêtement été un peu un outil de niche dans l’écosystème malgré son existence depuis 2015, étant donné la nécessité d’exécuter un nœud complet pour l’utiliser. Ce n’est vraiment que lorsque ZeroLink est arrivé sur le marché sous la forme de Wasabi et Samourai que CoinJoin est vraiment devenu un outil accessible et plus largement utilisé et compris.

Ces deux outils sont très précieux, mais en fin de compte, ce sont des services construits autour d’entreprises centralisées – même s’il s’agit de services sans confiance construits de manière à ce qu’il soit impossible de perdre de l’argent en interagissant avec eux – mais ce sont néanmoins des services. Que se passe-t-il si les entreprises ferment ? Le développement se poursuivra-t-il de la même manière, étant donné qu’il est actuellement financé par ces entreprises ?

Il y a absolument une place pour de tels outils dans cet espace, et ils présentent également des avantages. Cette même dynamique de financement qui remet en question la survie de l’outil si l’entreprise fait faillite garantit de nombreuses ressources pour son développement, tant que l’entreprise survit. Mais il y a aussi une place pour un outil décentralisé qui ne dépend pas d’une seule entreprise. Les progrès seront peut-être plus lents, et les problèmes plus compliqués à résoudre, mais s’il réussit, le résultat final sera beaucoup plus robuste et adaptable.

Source link