@ytreza et les autre.
Voici les grande ligne du protocole qui permettrait de générer un nombre aléatoire pour changer le salt tous les mois, n’hésitez pas à me dire ce que vous en pensez!
On suppose que l’attaquant possède 50% des noeuds, le reste des noeuds étant honnette.
On se base sur une fonction F de type “one way-permutation” sur de taille n (c’est à dire une sorte de Hash sans colision qui ne prend en entrée et en sortie que des chaines de n bits). On suppose que pour ce n donnée l’attaquant et les nœuds honnêtes possèdent tout deux une puissance de calcul permettant de calculer la fonction inverse F⁻¹ en 10000 secondes. Mais on considère que l’attaquant cache peut-être une puissance de calcul 1000 fois supérieure, par mesure de sécurité.
On imagine générer un nombre aléatoire tous les mois. En début de cycle (c’est à dire un mois avant d’avoir besoin du nombre aléatoire) les validateurs des 32 derniers blocks doivent emmètre en l’espace d’un temps d’une seconde, un commit composé d’une liste de 20 nombre F(xi). S’il ne le font pas on les ignore.
La probabilité que l’attaquant possède le contrôle des 32 derniers nœuds est environs de une sur 4 milliard, si on change de salt tous les mois, il faudra attendre en moyenne 33 millions d’années pour avoir le contrôle de tous les noeuds. On considère qu’il y a donc un nœud honnête au minimum.
La probabilité que l’attaquant puisse calculer toutes les fonctions inverse du commit du noeud honnête en moins d’une seconde est inférieure à (1/10000)^20=10^-80 en temps normal et 10^-20 si l’attaquant cache une puisse de calcul d’un facteur 1000.
Suite à cette phase de commit une récompense substentielle est offerte pour la résolution des fonctions inverse de chaque commit. Au maximum la résolution par brute force de cette opération prendrait 10000s = ~3heure de calcul pour les nœuds honnêtes. Bien sur celui qui a émit le commit connaît la solution sans aucun calcul. Dans ces conditions les attaquants n’ont aucun intérêt à ne pas révéler le nombre associé à leur commit: il perdrait une belle récompense, sans pour autant être capable de cacher bien longtemps le nombre associé à leur commit.
Dés que l’intégralité des fonctions inverses de chaque commit a été révélé, pour obtenir le nombre aléatoire on fait alors la somme bit à bit des 32x20 F⁻¹(x_i) commit qui ont été émis. Il suffit alors qu’un seul de ces nombres soit réellement aléatoire et non-connu de l’attaquant au moment ou il a réalisé ses commit pour obtenir un vrai nombre aléatoire non-biaisé.
(Une version un peu plus rafinée avec un pré-commit permet de limiter les dégat dans l’optique improbable ou l’attaquant aurait d’un coup une puissance de calcul bien au delas des limites imaginées, en ne lui permettant de ne biaiser qu’un peu le resultat, sans le determiner completement).