J’ai réécrit le programme de simulation et d’analyse de la sécurité d’un réseau ĞMixer, en passant du Python au Rust ça tourne littéralement 100 à 1000 fois plus vite. (le dépôt du programme utilisable en une commande)
Je peux donc simuler et “rétro-mixer” (si quelqu’un trouve un mot pour ça…) en 4 minutes, en faisant fondre les 4 cœurs de mon i5, environ 11000 transactions avec les paramètres suivants :
un unique montant de tx
expiration d’une tx non traitée après 288 blocs (1 jour)
expiration d’un mixage non terminé après 1008 blocs (3.5 jours)
3 couches d’oignon
4032 blocs (2 semaines)
200 clients
20 nœuds
“smart clients” activé
txmin = 5 (nombre minimal de txs en attente dans un nœud pour déclencher le mixage)
0.0035 txs/bloc/client (= 1 tx/jour/client en moyenne)
Le mode “smart clients” fait que les clients préfèrent envoyer une transaction aux nœuds n’ayant pas dépassé txmin, afin de maximiser les chances pour chaque transaction d’être traitée, et d’égaliser la charge entre les nœuds. Le désactiver divise par 100 la durée nécessaire au forensics.
Voici des graphiques. L’axe y est la probabilité qu’une tx entrante (client → nœud) soit la tx associée à une certaine tx sortante (nœud → client). Chaque point représente une session de mixage terminée. Plus la moyenne est basse, moins on a de chances de casser l’anonymat. Plus l’écart type est bas, moins il est facile de discriminer les différentes txs.
Plus de tests seraient nécessaires pour trouver des paramètres optimaux, et savoir comment gérer des cas particuliers tels qu’un changement de DU, ou s’il est dangereux de mixer des montants différents, voire d’appliquer une taxe.
S’il s’avère que je ne peux pas lancer assez de tests moi-même pour conclure, je proposerai de faire du crowd computing (avec un système tout beau tout simple où il suffira de lancer une seule commande et il fera tout tout seul).
Mon programme trace le graphe orienté de toutes les txs entre les nœuds. Il le remonte à partir d’une tx de sortie donnée, pour trouver toutes les txs d’entrée possibles, en sélectionnant celles qui ont le même montant.
Cacher le montant des txo permettrait de mixer le montant qu’on veut, sans altérer la sécurité. Cependant la sécurité serait égale à celle d’un réseau à un montant unique. (il me semble)
L’inconvénient, c’est que si la clé privée d’un nœud est publiée, alors on peut associer à partir de la blockchain ses txs entrées et sorties (qui ont le même montant). Il faudrait alors que les nœuds changent de clé privée périodiquement, pour réduire les dégâts en cas de vol d’ids.
On observe un anonymat très satisfaisant dès 2-3 jours (1 jour = 288 blocs).
Le changement de montant provoque comme prévu un arrêt total du mixage pendant quelques dizaines de blocs puis ça repart avec une baisse de l’anonymat qui se résorbe rapidement.
Les transactions sont généralement traitées en moins de 3h. C’est plus lent sans les clients intelligents.
Est-ce que tu connais les plans d’expériences ? J’ai appris ça dans mes études d’intérieur. C’ est une méthodologie pour déterminer, au moyen d’un nombre minimal d’expériences, quel est l’ implication ou le rôle des différents paramètres vis à vis d’une grandeur mesurable résultant de chaque expérience :
Exemple : temps de parcours entre la maison et le lieu de travail
Variables :
Trajet (NB de feux)
Condition météo
Heure de départ
Jour,
Le plan d’exp permet de tester un certains nombre de combinaisons (chaque combinaison étant testée x fois pour obtenir une moyenne et un equart-type) et d’ en déduire une équation déterminant le résultat en fonction des valeurs de paramètre.
Avec cette équation, on peut fixer des plages de valeurs permettant de maximiser le résultat dans le sens voulut.