Oui mais toujours par un tiers de confiance … et ça tombe bien il manque une personne pour finaliser le dernier mixage…
Pour l’instant je me concentre sur l’intérieur du mécanisme, pour que ça marche. Tant que la base ne sera pas fixée, on ne peut pas savoir comment devra être l’interface conviviale, donc il faudrait la réviser souvent.
Les versions 0.x seront pour les testeurs, et les 1.x pour tout le monde sachant se servir de la console.
Une jolie interface graphique me demandera plus de travail, comme je n’ai jamais fait ça avant. (en navigateur ça demande d’apprivoiser WASM, et en desktop il faut un truc du genre GTK, au pire electron) Si quelqu’un veut développer une interface dans la technologie de son choix et même sans toucher au Rust, ça serait chouette. 
Pas forcément, tu as plusieurs frameworks Rust te permettant de faire une GUI web sans avoir aucune notion de wasm : yew, seed, orbtk
Et pour une interface en desktop tu as plusieurs framework également : druid, orbtk, conrod
De mon côté j’attends la maturation du framework orbtk, qui permet d’avoir une gui web et desktop avec une même codebase !
Enfin, utiliser Gtk ou Qt en Rust n’est pas recommandé, ça reste possible pour les projets qui le nécessitent, mais ça complique fortement le build et l’install, et les API ne sont pas rusty, il vaut mieux utiliser des frameworks “Rust Centric Approaches” lorsque c’est possible 
2 Likes
Petit compte-rendu de l’avancement, parce que ça avance lentement, mais ça avance 
:
- Les transactions groupées (multi-destinataires) fonctionnent, le pire qu’il puisse arriver en cas de fork ou de bug est donc l’annulation du mixage.
- Le client peut envoyer plusieurs transactions en même temps.
- Les bugs et plantages du serveur ont été corrigés.
- On peut choisir d’enregistrer la clé de chiffrement du fichier DEWIF dans la config, pour pouvoir lancer le nœud automatiquement.
- Le serveur envoie chaque transaction à plusieurs nœuds Duniter au hasard.
Vous pouvez participer au test grandeur nature, soit en téléchargeant l’exécutable compilé (Linux) (Windows), soit en le compilant vous-même. Voir comment compiler, installer et utiliser ici.
Pour utiliser le client (donc anonymiser du 
), c’est tout simple. 
gmixer client mix -a MONTANT_EN_CENTIMES -r CLÉ_PUBLIQUE_DU_COMPTE_ANONYME
# on peut aussi refaire cette commande pour faire plusieurs mixages
# attendre une minute pour laisser l'oignon voyager
gmixer client confirm # cette commande confirme tous les mixages
gmixer client tx # cette commande envoie les transactions de tous les mixages confirmés
IMPORTANT : il faut que tout le monde choisisse le même montant pour que les transactions puissent être mixées rapidement. Pour le moment, utilisons 1 DU (10,23Ğ1 = 1023 centimes).
Il est possible d’héberger un serveur (IP statique conseillée) ou de tester seulement le client (plus simple). Dans les deux cas, synchronisez-vous sur txmn.tk (à mettre après la sous-commande sync -n).
Pour vérifier si votre nœud fonctionne, mettez RUST_LOG=info devant la commande du serveur, ça affichera le log. Il rapporte toutes les connexions aux autres nœuds, étapes de mixages et transactions.
Pour faire tourner un serveur, il faut avoir un nœud IPFS.
Les testeurs seront rémunérés par ce compte de don : HVXB7mrnrLDfJVALZiZknFg8FgPPi5k4y1md6GCLYGEK
6 Likes
En voulant utiliser le client j’ai cette erreur:
thread 'main' panicked at 'Not enough nodes', src/client/mod.rs:46:44
Du coup je suppose qu’il faut que je le synchronise sur un autre noeud, mais lequel existe déjà ?
SI je veux lancer le serveur même question, existe-il un noeud sur lequel on peut se sync ?
En lançant un serveur en local, et en essayant d’utiliser le client sur ce serveur (sur le même PC), il me dit bien Added NodeSig avec une clé et son adresse, mais j’ai toujours la même erreur de pas assez de node lorsque j’essai de mixer. Du coup je ne sais pas combien il veut de node au minimum ?
Pour profiter des derniers commits, tu peux aller sur la branche gva.
Oui, j’ai 3 nœuds qui tournent (on peut sync sur txmn.tk).
Par défaut il faut 3 nœuds pour mixer. Le client ira chercher 3 nœuds au hasard parmi ceux qu’il connaît. On peut changer cette valeur avec l’option -l.
Pour les tests, j’ai mis min_txs_per_mix dans la config du serveur à 1, donc chaque transaction est traitée immédiatement, sans attendre d’en avoir plusieurs. Par défaut c’est 5 donc il chaque nœud attend d’avoir 5 txs prêtes et du même montant pour les mixer.
# utilisation du serveur
gmixer server init
# éditer ~/.config/gmixer/server/config.json à la main
gmixer server sync -n txmn.tk
gmixer server sig # signe la clé publique du nœud avec la clé de l'identité membre
gmixer server start
# utilisation du client
gmixer client sync -n txmn.tk
gmixer client node # affiche les nœuds connus
gmixer client mix -a <montant_en_centimes> -r <pubkey_destinataire>
# attendre 1-2 minutes que l'oignon fasse l'aller-retour
# on peut faire cette commande plusieurs fois pour faire plusieurs transactions
gmixer client confirm # demande la confirmation aux nœuds pour chaque mixage
gmixer client tx # envoie toutes les transactions en attente
gmixer client track # affiche l'état de chaque transaction en cours (permet de surveiller le travail des nœuds)
La commande track est toute neuve, elle fonctionne bien mais son affichage nécessite de bien comprendre le protocole. Elle nécessite également un accès à GVA (nœuds listés dans la config) et à une API IPFS (listées dans la config).
IPFS étant trop lourd, trop boîte noire et trop compliqué dans certains cas, je vais le remplacer par un truc fait maison (faisant partie du protocole).
3 Likes
Je viens de lire la page de présentation du système et je me demandais: même en ayant un gros volume de transfert, il y a toujours un risque important qu’une transaction soit identifiable à cause du montant qui pourrait être unique au sein d’un groupe de transactions non ?
Pourrait-on renforcer ce système en incluant une commission dans la transaction ?
Par exemple, moi, A, je souhaite envoyer 1 DU à B, et je vais passer par 3 noeuds N1, N2, N3. J’envoie ensuite 1.4 DU à N1, avec comme message d’envoyer 1.3 à N2 ainsi que l’ordre d’envoyer 1.1 à N1, puis 1.0 à B. De cette manière, même si le je suis la seule transaction « réelle » 1 DU dans une plage donnée, cela serait difficile à tracer.
Éventuellement, l’ordre pourrait être « au moins le montant X », permettant aux mixeurs de d’adapter la commission afin de fondre la transaction avec d’autres en utilisant les même montants ?
Je viens de me rendre que non, un montant ne sera pas unique puisque chaque noeud attend d’avoir X transactions de même montant. Mais ne risque-t-il pas souvent d’y avoir un manque de transactions ? Tous les nombres étant possibles, il risque d’être compliqué d’avoir plusieurs fois le même montant… Y-a-t-il un mécanisme d’expiration des contrats ?
C’est justement pour ça qu’il faut que toutes les transactions qui sont mixées ensemble aient le même montant.
C’est codé comme ça dans le logiciel : les serveurs acceptent tous les montants, et mixent toutes les transactions en attente d’un même montant, dès qu’il y en a au moins 5 de ce montant. (le seuil de 5 étant paramétrable)
Il faut donc qu’on se mette d’accord pour tous utiliser un ensemble restreint de montants différents. La sécurité croît avec le nombre de transactions d’un même montant, mais si chaque transaction a un montant différent, alors il n’y a aucun anonymat.
J’ai pensé aux frais de transaction, mais cela permettrait de savoir facilement quel est l’étape d’une transaction s’il est appliqué à chaque nœud. Cela créerait de plus plein de montants différents. Ces deux problèmes peuvent être évités en n’ajoutant les frais que sur les nœuds entrants et sortants, ce qui se tient aussi car ce sont juridiquement les plus périlleux. (même problème que les nœuds de sortie Tor)
Oui les contrats expirent, pour le moment j’ai choisi des durées de l’ordre d’une semaine.
Il faut en effet une fréquentation minimale pour que les transactions soient traitées. J’ai pensé à des bots qui enverraient des transactions inutiles en permanence (une quinzaine par semaine devrait suffire pour qu’aucune transaction n’expire, ou plus en fonction du nombre de nœuds et de l’algo de sélection des nœuds des clients), mais il faudrait que ces transactions soient envoyées par plusieurs personnes différentes pour qu’elles ne puissent pas tracer les autres.
Pas forcément, j’ai essayé d’expliquer avec l’exemple, mais ça n’était peut-être pas assez marqué:
Les “frais” seraient décidés par le seul commanditaire (c’est pour ça que j’ai parlé de commission). En somme, le contrat serait non plus “je t’envoie 1, envoie 1 au noeud suivant”, mais “Je t’envoie 1, envoie 0.6 au noeud suivant”, et le noeud suivant recevrait en message “je t’envoie 0.5, envoie 0.5 au noeud suivant”. Du coup impossible de savoir où on en est non ? Point de vue utilisateur, il suffirait de renseigner le receveur, le nombre de noeuds, le montant total de commission et le client choisirait aléatoirement la répartition par noeud.
Sur le principe j’entends, mais est-ce vraiment viable dans la pratique ? Chaque objet ou service ayant une valeur propre (et parfois subjective), il y aura forcément énormément de montants différents 
Si on se limite à des montants entiers en Ğ1, on peut se baser sur des puissances de 2 :
1, 2, 4, 8,…
Ainsi, si je veux envoyer 153 Ğ1, j’envoie des tx mixées de 128, 16, 8 et 1 Ğ1. Pour qu’elles soient envoyées à une même personne mais à des clefs publiques différentes, il faudra s’appuyer sur les HDWallets. Tout un chantier 
2 Likes
Mais si chaque nœud peut appliquer une commission, alors on se retrouve avec plein de montants différents.
Or, si la même commission est prélevée sur toutes les transactions qui sont mixées ensemble par un nœud, et que ces transactions ont des montants différents, alors on peut les tracer. Il faut donc que la commission du nœud soit aléatoire, avec une marge assez grand pour pouvoir mixer ensemble à la fois des txs en début de chaîne et des txs en fin de chaîne, mais pas trop. Il y aurait donc parfois des transactions juste en-dehors de l’intervalle, qui auront beaucoup plus de mal à être mixées.
Actuellement, le client fait sa requête aux nœuds afin d’obtenir les contrats, puis les vérifie et envoie la tx. Si les montants des commissions sont inclus dans les contrats, alors le client va probablement chercher à avoir les commissions les plus faibles, ce qui va réduire l’anonymat de tout le monde. On pourrait aussi mettre dans le contrat que le montant compris dans un intervalle donné, la commission étant choisie par le nœud au dernier moment (en respectant l’intervalle). Il faut étudier les conséquences de cette solution.
L’idée est plutôt de se créer des portefeuilles anonymes, puis de les utiliser pour payer avec le montant voulu.
Si on met une liste prédéfinie de montants dans l’interface client, avec un mode expert pour mettre un autre montant (avec avertissement), ça devrait suffire pour éviter le fleurissement de montants exotiques.
Bonne idée ! Simple et efficace.
Oui, cela créerait des transactions avec des montants qui n’ont pas de lien entre eux, c’est justement cela qui rendrait la chose discrète.
J’imaginais plus un système où l’utilisateur choisi la commission totale, et le client réparti aléatoirement. Plus la commission est faible, moins la transaction est discrète, mais c’est l’utilisateur qui la choisi, cela n’impacte pas les autres. Dans l’idée que je décris, ce n’est pas les noeuds qui donnent leur tarif, il est entièrement libre. En tant qu’utilisateur, si je mets une commission à zéro, cela revient à utiliser le Ĝmixer dans son fonctionnement actuel “normal”.
Si je comprends bien cette phrase, le principe du Mixer n’est pas à terme de mixer toutes les transactions, mais plutôt uniquement les transferts “Moi” vers “Un de mes portefeuilles que je veux garder secret” ? Dans ce cas oui j’avais mal suivi et utiliser des montants ronds a tout à fait son sens, et le problème de latence n’en est effectivement plus un !
Une commission plus forte ne crée pas forcément plus d’anonymat, et tout l’anonymat repose sur ce que font les autres.
L’anonymat et l’efficacité augmentent avec le nombre de transactions ayant le même montant. Un montant unique sans aucune commission est dans tous les cas le plus efficace et le plus sécurisé.
Avec le découpage des transactions en montants standard comme les puissances de 2, on peut toutefois faciliter les commissions et augmenter le nombre de transactions…
Le protocole permet déjà (en théorie, j’ai pas encore testé) de faire une bonne partie de tout ça. Je dois d’abord essayer de le faire marcher sans commissions et sans découpage…
Oui, mais on peut aussi se créer un nouveau portefeuille anonyme pour chaque paiement, pour plus de sécurité.
Plus la commission est élevée, moins la transaction est reconnaissable entre le départ et l’arrivée, et cela n’empêche pas forcément de toujours utiliser des valeurs “communes” comme proposé ! Ceci étant dit, j’ai du mal à me former un avis définitif, c’est typiquement le genre de sujet ou un mathématicien ou un modèle informatique pourraient avoir le fin mot de l’histoire sur le niveau d’anonymat en fonction des différentes options. En soi, si la porte à un tel système reste ouverte, c’est suffisant: la conception sans com/frais fera son chemin et il sera plus facile de constater l’efficacité une fois un grand nombre de transactions faites.
Merci pour les réponses en tout cas !
1 Like
J’aurais bien du mal à faire un modèle mathématique…
Par contre il y a un début de simulation informatique : Étude de la sécurité du ĞMixage
Si on ajoute des mécanismes complexes de commission et de découpage, il faudra adapter la simulation et trouver un algo d’attaque.
Et là c’est pas pour moi 
Et ça couvrirait la partie “théorique”, mais je suis sûr que c’est plus compliqué. Y’aura sûrement dans la pratique des points “repère” qui permettront de prendre des “raccourcis” sur les stats (site marchand qui n’a qu’un portefeuille de destination par ex ?). C’est un peu comme la sécurité info, y’a des magiciens côté attaquant donc je préfère laisser d’autres magiciens déterminer ce qui est “sûr” ou pas, ensuite j’applique 
Bien vu d’avoir fait ces tests pour cette partie en tout cas
N’existe-t-il pas un moyen d’isoler et de visualiser (à la manière du graphisme de la wotmap) la nébuleuse d’anonymisation? Il me semble que oui
A partir de la on devrait voir ce qui entre et ce qui sort et ranger les montants les plus probables en tenant compte qu’il en ressort ce qui entre moins des frais.
On aurait donc des informations sur les départs et arrivées des transactions cachées.
Dans ce cas une meilleure anonymisation se ferait avec des comptes qui interagissent régulièrement dans les deux sens avec de véritables personnes. Mais là c’est quasi impossible à faire.
Oui, on peut construire un graphe représentant les transactions, et le dessiner, cependant je ne saurais pas comment le dessiner : il faudrait voir quelles transactions ont été mixées ensemble, de quel nœud à quel nœud, et pouvoir ordonner les mixages dans le temps.
Mais pas besoin de le dessiner, ĞMixer-analyzer fait déjà tout ça automatiquement.
Il me semble que c’est plutôt l’inverse : plus il y a de transactions entre deux mêmes comptes, plus on a d’indices que les deux sont liés.
Par exemple, une attaque contre le réseau Tor est l’envoi massif de requêtes vers un serveur caché (.onion). Ce flux inhabituel est détectable (par la quantité de données à un moment précis uniquement) par les autorités et les FAI, on peut le tracer plus facilement jusqu’au serveur cible.
Si on trouve qu’à chaque fois que A mixe une transaction, B en reçoit une, une heure après, alors on est quasi-sûrs que A envoie à B. C’est pour ça que les comptes anonymes devraient être à usage unique.
1 Like
C’est pour ça qu’il faut spliter les transactions et les étaler dans le temps.
Je n’invente rien, c’est ce que font tout les anonymizer de bitcoin dignes de ce nom.
1 Like