GMix - Nouvelle fournée ?


#1

Bonjours à tous,

je relance une fournée d’anonymisation pour vos précieuses Junes… :g1::male_detective:
Comme d’habitude merci de suivre la procédure détaillée ci-dessous :


#2

Dommage que le montant soit fixe, j’ai pas assez. ^^

Je participerai à la prochaine. :slight_smile:


#3

Le problème, c’est que le mixeur connaît les comptes anonymes…

Et si, pour être vraiment anonyme, on faisait comme Tor : il y a plein d’instances de GMix sur le réseau, appartenant à des personnes différentes. Pour GMixer une transaction, on l’envoie à une instance avec un message chiffré pour sa clé contenant la clé publique d’une autre instance GMix ainsi qu’un message chiffré pour cette dernière clé. L’instance qui a reçu la transaction renvoie l’argent à l’instance indiquée sur le message. On recommence jusqu’à la dernière couche du message, qui contient la clé publique du compte anonyme.

Résultat si on utilise 3 couches : le nœud d’entrée connaît le compte d’origine, le nœud de sortie connaît le compte d’arrivée, celui du milieu ne sait rien.


#4

En fait tu proposes un mixeur de mixeurs… pas mal ça !


#5

Pour l’instant, est-ce que tout est fait à la main ou il y a un logiciel ?


#6

Pour ma part je fais ça à la main…


#7

Il faut par contre avoir confiance dans des mixeurs qui eux sont anonymes. Si ils envoient la monnaie vers le compte d’un voleur, on a l’air malin !

Il faudra peut-être jouer avec les mécanismes de verrous, un peu comme font les lightning network, pour se protéger de noeuds malhonnêtes.


#8

En effet, c’est fâcheux. :frowning:

En attendant j’ai commencé à écrire un ĞMix en Python avec duniterpy. En même temps que la transaction il faudra envoyer une requête HTTP avec les clés publiques chiffrées en oignon.


#9

Up !

D’autre personne ?


#10

Je t’ai répondu sur l’issue GitLab, comme il ne fait pas de notifications tu n’as pas dû le voir.

J’avais gardé le même nom car mon programme a pour but de remplir la même mission que ton mixeur manuel, et je trouvais logique que toutes les implémentations de mixeur de Ğ1 puissent être appelées ĞMix (le nom semble assez générique, et par exemple on a duniter-ts et duniter-rs). En gros le nom est celui du concept, pas celui d’une des mises en œuvre du concept.

Donc je pourrais renommer le projet ĞMix-py, ou ĞMixer-py si tu préfères garder l’exclusivité de ĞMix.


#11

effectivement je l’avais pas vu :wink:

c’est pas tant l’exclusivité du nom mais surtout que les gens comprenne bien que “mon ĞMix” est manuel, que je suis le seul tiers en qui il faut avoir confiance par exemple…


#12

Ok donc si j’appelle le mien ĞMixer-py, ça insiste sur le fait que c’est un mixeur, donc une machine, et on peut faire la différence.

Edit: C’est bon, ĞMixer-py. Il ne me reste plus qu’à comprendre comment fonctionnent les transactions (ou utiliser silkaj comme bibliohèque).

Edit 2: Je pense avoir trouvé un système pour éviter le vol par les nœuds (j’aurais préféré poster ça sur le forum technique car c’est très technique, mais il est en lecture seule) :

A (le client, émetteur de la tx) génère N (nombre de nœuds mixeurs) clés publiques à usage unique, dont il garde les identifiants. Avec N=3 : A1, A2, A3. Les nœuds sont P1, P2, P3. Le compte receveur est B. Le montant est M.

A envoie sa requête en oignon (décrite au dessus) mais ajoute les clés publiques A1, A2, A3 respectivement chiffrées pour chaque nœud. P1 connaît donc A1, etc.

Quand le dernier nœud (P3) a reçu la requête, il génère deux chaînes aléatoires C3 et CB. Il signe un document disant “Quand je recevrai une transaction de P2, d’un montant M avec le commentaire C3, je m’engage à envoyer une transaction à B, d’un montant M, avec le commentaire CB.”. Ce document est ensuite chiffré pour A3, et envoyé à P2 collé avec C3. P2 fait de même et passe le message à P1 avec en plus le document de P3. P1 fait pareil et donne tout à A.

Ainsi, A est en mesure de vérifier que chaque nœud effectue la bonne transaction. Si un nœud triche, A publie anonymement le document signé par ce nœud pour le discréditer. Par contre si le client triche et n’envoie pas la transaction, il ne peut pas faire passer le nœud pour un voleur car le document dit “SI j’ai reçu telle transaction”.

Voyez-vous des failles dans ce protocole ? (ou dites-le si les explications ne sont pas claires)


#14

Encore quelques jours et j’allume le mixeur :wink:


#15

4 personnes, ça ne me paraît pas vraiment suffisant… il faudrait au moins 10, non ?