Du pur génie 
L’outil de crowdcomputing est prêt ! 
Il suffit de télécharger le script (lien dans le pad) (et d’avoir bash, python3 et curl installés), et d’exécuter une commande (après avoir mis votre nom au-dessus dans le pad, pour se répartir les tâches). Les résultats seront automatiquement envoyés au serveur. (ils seront publiés quand j’aurai programmé cette fonction 
)
Le pad : https://pad.aquilenet.fr/p/gmixer-analysis
Les participants seront rémunérés en Ğ1.
Sur mon i5 7e génération, une commande met au moins un quart d’heure, donc prévoyez du temps, surtout si vous utilisez un RPi.
2 Likes
Bonjour tout le monde,
Pour lancer les taches (sachant qu’une tache peut etre lancé plusieurs fois par une meme personne) j’ai realisé deux scripts et un fichier de service. Un script sans tor et un script avec tor
Il faut juste adapter la variable path_script dans le script avec votre chemin où se trouve txmix.py et le script shell. Il faut également adapter le fichier de service avec votre user, le groupe de votre user et le chemin où se trouve le script shell.
Le script shell lance en continue les tâches choisies de manière aléatoire.
Il faut renommer le fichier txmix.txt joint en txmix.service et le mettre dans /etc/systemd/system si vous êtes sous debian.
Bon crowdcomputing !! script_txmix_tor.txt (2,4 Ko) script_txmix.txt (2,1 Ko) txmix.txt (307 Octets)
2 Likes
Avec la page d’explication, j’ai compris en quoi les noeuds Gmixer ne peuvent pas faire le lien destinataire - emetteur.
Le système intègre-t-il un algo pour être sûr.e que plusieurs fonds (par ex. au moins 5) en entrée sont passés par le même noeud mixer à un moment ? Est-ce une condition à chaque étape du mixage ? Ou bien ça doit être un choix fait de la part de X personnes d’envoyer leurs fonds sur un même noeud GMixer ? Et dans ce cas, y a-t-il un délai pour regrouper les X transactions ?
Tel que présenté, il semble simplissime de suivre une tx unique de compte en compte sur la Blockchain. J’ai juste besoin de comprendre comment est organisé le seuil de 5 tx pour déclencher le mixage avant d’utiliser cet outil.
Effectivement on ne peut être sûr a priori que la tx va être écrite par un nœud en même temps qu’au moins 4 autres. Tout ce que peut faire le client est vérifier que la pubkey du nœud écrit dans le même bloc au moins 4 autres txs ressemblant à des txs ĞMixer.
Du coup il faut compter sur le fait qu’il y ait en permanence un assez grand nombre de txs à mixer. Si le nœud n’a pas respecté le seuil auquel il s’est engagé, le client pourra le discréditer.
La faille est que le nœud peut envoyer systématiquement 4 txs à des comptes complices en même temps que chaque tx authentique. Ses complices pourront alors tracer la tx. Cependant, cela suppose toujours un réseau de nœuds complices. Si celui-ci existe, il n’a pas besoin d’un tel stratagème pour pister ses txs, alors exploiter cette faille semble inutile.
Je pense mettre un délai avant de retourner la tx à l’envoyeur, pour éviter de perdre de l’argent à cause d’un problème technique ou d’une baisse d’utilisation. Là encore, la tx de retour devra être pistable par le client et fera partie de l’engagement du nœud.
Donc de ce que je comprends :
- chaque noeud s’engage à faire passer les tx uniquement s’il a un nombre minimal de txs à mixer
- s’il ne le respecte pas (ou s’il vole les unités), le client peut révéler cette fraude pour blacklister les noeuds administrés par la même personne
- en cas de réseau faiblement utilisé, les X personnes ont plutôt intérêt à se concerter.
Hum, non ? Il faut que le client vérifie que, le compte mixer ayant reçu X montants identiques, a renvoyé X fois le même montant dans un intervalle de temps court. Pas forcément dans le même bloc.
1 Like
Oui, j’avais oublié de dire qu’on peut aussi vérifier qu’il n’y a pas plus de txs sorties que de txs entrées et que leur montant est le même.
Pas forcément dans le même bloc, mais ça assure qu’entre 2 txs sensées être mixées ensemble, l’une passe par 2 nœuds pendant que l’autre est en attente, ce qui permettrait de les pister.
Voilà, il était temps, je viens de commencer ĞMixer-rs, l’implémentation en Rust. J’en profite pour modifier complètement les formats de données, et — c’est le topic sur le format de trousseau qui m’y fait penser — que ceux qui souhaitent participer à l’élaboration de ce protocole le fassent tant qu’il n’est pas trop coûteux de revenir en arrière (que ce soit pour des suggestions/critiques).
Je vais a priori utiliser :
- Encodage pour le réseau et les signatures : bincode (+ cbor et json pour l’API si besoin)
- Mixage : protocole actuel
- Surcouche sécurité réseau : pkstl (si besoin)
- Découverte des pairs : Swarm libp2p (ou alors il faut voir ce qu’on peut faire avec pubsub)
- Crypto : ring
J’ai implémenté un document de signature de clé publique, pour qu’une clé membre puisse déléguer temporairement le pouvoir de ğmixage à une clé non membre. Je me dis que ça serait cool d’avoir un format commun à plusieurs applications, avec un champ application qui dit quels droits on donne à la clé signée : ğmixage, forge… si ça vous intéresse pour la prochaine version de DUBP ou pour d’autres clients par exemple.
3 Likes
Alors oui, j’ai réfléchi à quoi pourrait ressembler un client Ğ1 anonyme(1), et je me dis que concernant le seuil de mixage, il faudrait que chaque nœud attende d’avoir un certain nombre de transactions en cours de même montant (5 p.ex) avant de déclencher la transaction suivante, pour ces montants uniquement.
Ainsi, ça permettrait à un client d’anonymiser des montants entiers quelconques, en les convertissant en base 2 et en anonymisant chaque “tranche” vers une clef pub différente.
On regrouperait plusieurs clefs pub anonymisées pour faire les dépenses.
(1) Je me sens pas la légitimité pour publier ça, vu que j’ai pas les compétences pour en coder 1/10e. Mais si ça vous intéresse, je peux le rendre disponible.
2 Likes
Oui c’est déjà le cas dans ĞMixer-py, et effectivement c’est nécessaire à l’anonymisation.
Edit: le dépôt sur le GitLab
3 Likes
La toute première transaction écrite par un client Rust est dans le bloc 304329 !
ĞMixer-rs peut maintenant grâce à BMA vérifier une identité ou une tx et envoyer une tx. J’ai dû faire plein de tests parce que la doc n’est pas claire sur le sujet (faut-il signer ou non le \n final, faut-il un \n final, \n ou \\n, entêtes HTTP).
1 Like
Tu aurait pu gagner du temps en te servant des tests unitaires de Dunitrust dans la crate dubp- user-docs , il y a déjà tout ce qu’il faut dedans pour générer un document transaction valide, c’est dommage de réinventer la roue 
Ah oui, je n’y avais pas pensé. Par contre j’ai utilisé dup-tools et ai regardé comment font Cesium et Duniterpy.
1 Like
Petit compte-rendu de l’avancement de ĞMixer, pour les curieux :
Le protocole de préparation du mixage a été testé avec la version Rust, et ça fonctionne ! Le client envoie sa demande à un nœud, la demande est relayée de nœud en nœud, et arrivée au bout la confirmation est relayée jusqu’au client, qui la vérifie avec succès.
J’ai plus ou moins prévu 3 étapes pour le moment :
- v0.1.0 – le mixage marche, mais pour les geeks (interface rudimentaire). Le discrédit et l’identité (TdC) des nœuds ne sont pas pris en compte.
- v0.2.0 – le protocole est complètement implémenté. Un nœud peut donc être discrédité et on vérifie l’identité des nœuds.
- v1.0.0 – facilement utilisable en ligne de commande, testé, optimisé. La GUI (client web ou desktop) devrait être la prochaine étape.
Avant la v0.1.0, il reste à terminer et tester le mixage de la transaction, à peaufiner l’interface du client, améliorer la gestion du réseau et quelques petits trucs.
Je ne sais pas encore comment gérer les forks. (je pense qu’un document de discrédit sera nécessairement relié à un bloc de la blockchain)
Quand la v0.1.0 sortira ou que j’aurai fini de rédiger le protocole, je vous demanderai de tester … et toute découverte de bug, faille de sécurité de l’implémentation ou du protocole sera dûment récompensée en Ğ1 ! 
6 Likes
Super travail. Mais pour l’instant le gmixer semble etre réservé à une utilisation par les informaticiens (s’est un peu technique en interface, installation, ligne de commande). Ce serait possible d’anonymiser les transactions simplement en option via Cesium? Ou pourquoi pas carrément que par defaut toute les transactions soient anonymisés? (il me semble que ce serait un peu mieux que de pouvoir voir les comptes de tout le monde non?) Pourquoi ca implique des frais quand ca passe par plusieurs noeux?
Merci!
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 ?