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).
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
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.
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.
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.
Ce soir je suis content car j’ai enfin réussi à mixer une transaction de bout en bout, après avoir corrigé plein de bugs à la noix ! C’est la première fois que ça remarche depuis l’ajout de la DHT au protocole (DHT qui reste grandement à améliorer).
Voir mon historique de transactions, la tx de 1,03 Ğ1 est passée par 3 nœuds puis est revenue à moi. Je ferai d’autres tests avec plusieurs transactions demain.
Je travaille aussi à une présentation du ĞMixer pour le Hackathon…
Développement d’une interface graphique en navigateur (destinée à être utilisée en local comme Cesium, pour des raisons de sécurité), en web-assembly (WASM), ce qui permet de garder la même base de code Rust et de ne pas faire une ligne de JS.
protocole entièrement implémenté jusqu’à l’envoi de la transaction (demande de mixage, attente de la réponse, vérification de la réponse, envoi de la transaction)
stockage des mixages dans le navigateur (local storage)
teste tous les nœuds connus jusqu’à en trouver un qui fonctionne
peut gérer un trousseau différent par mixage
À faire :
chiffrement des données stockées avec une/des clés maîtresses
traçage des transactions (pour vérifier que les nœuds font le job)
pouvoir modifier la config
liste de nœuds dynamique
envoi groupé
demander confirmation avant envoi (avec affichage des détails)
afficher globalement plus d’infos
autres méthodes d’authentification (pour l’instant c’est scrypt)
easter eggs (c’est le plus important)
C’est la première fois que je fais un programme WASM, donc je commence par implémenter les fonctionnalités de base pour voir quelle structures adopter, avant de travailler sur l’UX et le graphique. Question structure, il reste à :
gérer/afficher/logger les erreurs
gérer les tâches de fond (montrer ce qu’il faut à l’utilisateur, éviter de lancer 2 fois la même tâche, attendre quand il faut…)
actualiser seulement certains bouts de la page (actuellement on régénère toute la page à chaque changement d’un élément, ce sera trop lent et ça pose des problèmes avec les formulaires)
système de boîtes modales et de formulaires plus propre
Dès que l’envoi de transaction fonctionne bien je vous mets une démo à disposition
J’ai trouvé un moyen de mixer avec des frais de transaction (qu’ils viennent de la blockchain ou des mixeurs) :
Chaque nœud envoie la transaction au nœud suivant en ajoutant un complément de sa poche, afin que le montant qu’il envoie soit égal à celui qui lui a été envoyé avant que les frais soient appliqués. Il fait donc une avance au nœud suivant, égale aux frais de la transaction qu’il a reçue.
Le nœud sortant envoie au destinataire le montant sans les avances, donc le montant envoyé par l’expéditeur moins la somme des frais jusqu’à lui.
Dans le temps, les dettes entre nœuds vont s’accumuler, il faut donc que les nœuds se remboursent périodiquement. Il faut aussi qu’ils disposent d’un fonds propre, proportionnel au débit maximal de transactions qu’ils prétendent pouvoir gérer.
Les nœuds peuvent demander des frais supplémentaires aux frais de la blockchain afin de rembourser les frais des transactions qu’ils devront faire pour se rembourser entre eux.
Il faudra bien définir les conditions de remboursement entre les nœuds, pour savoir quand considérer qu’un nœud triche. Il faut aussi qu’un nœud non remboursé puisse le prouver publiquement, idéalement sans dévoiler l’intégralité du contrat.
Cela permet de garder un montant identique pour toutes les transactions, quel que soit son avancement dans le mixage. Donc de pouvoir mixer des transactions ensemble, même si elles ont un avancement différent. Donc d’augmenter significativement le débit et l’anonymat. Cela empêche aussi de savoir quel est l’avancement d’une transaction juste en regardant son montant, ce qui rend plus difficile certaines attaques.
Je vais essayer de faire les équations et je donne un exemple avec Alice, Bob et des valeurs numériques.
(c’est le plus important)