Comment tu prouves à tous qu’il n’est pas de la bonne longueur et que tu as bien fais les calculs pour en être sur, juste à partir du hash, très compliqué. Si tu prend une fonction de type “one way permutation”, ça résout le problème.
Oui pour la captcha je me suis penché dessus, c’est impossible aujourd’hui. En plus, on n’a pas envie de résoudre des captchas en permanence pour faire tourner la monnaie…
Ça aurait été 32 par mois pour tous le réseau, je pense que ça aurai été soutenable.
Au début on ne se préoccupe pas de sa taille puisqu’elle est inconnue. On ne peut pas prouver qu’il est invalide, seulement qu’il est valide. La seule chose qui fait que le nombre est pris en compte, c’est qu’un membre le trouve. Si aucun ne le trouve, il est juste considéré invalide.
Là je montre seulement que ça peut fonctionner en utilisant du SHA, mais je suis d’accord sur le fait qu’utiliser la permutation permet d’éviter de perdre son temps à essayer avec des commits invalides.
La taille maximale des blocs est évolutive :
Le nombre de tx par seconde aussi, par conséquent.
Il faut que je vous partage ce magnifique billet explicatif relatif au problème de la synchronisation dans un système distribué. C’est une vraie mine d’or, très bien vulgarisé ! (attention, requiert un certain niveau technique quand même).
De quoi bien baliser le terrain pour éviter de partir sur une fausse route 
je l’aurais eu à mes débuts, j’aurais éviter de perdre 2 semaines sur mes histoires d’amendements, où au final j’ai fini par reprendre la solution PoW.
Très inspirant.
Je voudrai rajouter un point que j’ai découvert récemment ( dans une présentation de Ourobouros ) pour générer les hasard de manière distribué et fiable:
Il est possible d’utiliser une technique de “publicly verifyable secret sharing” ( Publicly Verifiable Secret Sharing - Wikipedia ), qui permet à quelqu’un d’envoyer au réseau de manière chiffré un message qu’il a généré (en l’occurence une chaine aléatoire), et d’envoyer aux différent noeuds du réseau des bouts d’information, de telle manière que la majorité d’entre-eux s’ils s’assemblent puissent retrouver le secret original, mais qu’une minorité ne puisse en déduire aucune information.
Cela permet à une majorité de générer du hasard sans qu’une minorité ne puisse le biaiser. Car chaque participant crée un commit, sans qu’une minorité ne puisse connaître le résultat correspondant. Et on est assuré que si la majorité est honnête et coopérative, on disposera de tous les reveals à la fin d’un processus de génération aléatoire distribué: si celui qui a généré le commit ne veut pas faire le reveal, la majorité des nœuds peut le faire à sa place.
Cela parait nettement plus valable et moins tiré par les cheuveux que l’histoire du brutforce inverse des Hash de type “One way permutation” que j’avais proposé au post 83.
Ce protocole n’est valable que dans le cas d’une majorité honnête, contrairement à l’article que j’ai posté plus haut ( https://eprint.iacr.org/2012/643.pdf ), qui a l’avantage de fonctionner avec une majorité non-honnette, mais parait nettement plus complexe à mettre en oeuvre.
Je pense qu’une telle technique pourrait être assez facilement adapté à Duniter pour générer du hasard qui ne puisse pas être biaisé, à partir du moment ou tous les acteurs de la blockchain sont des membres bien identifiés, dont la majorité sont supposé honnêtes.
