Duniter utilise la POW?

Une solution pour mitiger la manipulation du random, c’est de faire en sorte qu’on ne tire pas au sort qui va produire le block, mais qu’on tire au sort l’ordre des membres qui vont produire les blocks, comme ça tout ce que peut faire l’attaquant c’est changer l’ordre.

Ca me parait pas forcement satisfaisant, si le hasard ne sert à rien et que c’est pas grave si on peut l’attaquer, alors autant ne pas faire de hazard.

Quand je disais plus compliqué je ne parlais justement pas de la partie commit reveal, mais du reste.

Oui c’est une piste aussi, à voir si le fait que l’ordre de production des blocks soit toujours le même ne permet pas d’autres attaques.

Une attaque possible c’est que si l’ordre est toujours le meme, tu peux (dans les blockchains classiques PoS classiques, dans duniter je sais pas) diviser ton stake en plusieurs adresses et faire en sorte qu’elles soient tirées au sort consécutivement, et donc au final produire pleins de blocks à la suite, ce qui te permet de faire une attaque double spend plus facilement.

Donc il vaut mieux faire un ordre aléatoire.

1 Like

Quand je disais autant ne pas faire de hasard, ce n’était pas une proposition. C’est pour dire que pour moi s’il est nécessaire d’utiliser du hazard, il faut qu’il soit bon.

La solution sans hazard pose des problème pour l’arrivé de nouveaux membre qui peuvent choisir leur clef publique comme ça les arrange.

Je ne sais pas ce qui signifie “partir dans tous les sens”, mais si ça signifie “développer une monnaie libre quand personne d’autre ne le fait”, je crois que je préfère ce chemin.

C’est du niveau logiciel, c’est possible, mais il me semble que ce n’est pas de cela dont nous parlons. Nous évoquons le protocole ici.

Et à ce sujet je crois que je ne suis pas compris : le protocole sert à imposer des règles à ceux qui voudraient participer. Actuellement, la règle de PoW de Duniter oblige tout participant à réaliser une preuve par les moyens qui lui conviennent, Duniter est totalement agnostique de cela. Et bien entendu cette règle est pensée dans le but d’obtenir l’effet escompté : un bloc en moyenne toutes les 5 minutes pour la Ğ1.

À contrario, une règle qui dit “ne pas accepter de blocs arrivé il y a moins de 5 minutes” n’est pas imposable à autrui, car elle ne repose pas sur le protocole mais sur un système externe sur lequel on n’a pas la main.

Bref, ce type de règle introduit une nuisance possible de ceux qui ne voudraient pas respecter cette règle, là où ce n’est pas possible avec la PoW actuelle de Duniter.

2 Likes

Je ne critiquais pas le côté toile de confiance et monnaie libre, c’est tout simplement génial.
Je critiquais le reste : le mécanisme de PoW pour tirer au sort le prochain producteur de block.

C’est possible de nuire d’une manière similaire dans Duniter : tu crées des blocks alors que tu n’es pas tiré au sort (tu n’as pas trouvé de PoW) : ton block n’est pas valide, et tu occupes de la bande passante pour rien.

Tu notera que ce n’est pas ce que j’ai dis, une telle règle poserai problème car tous le monde enverai un block exactement au meme moment.

Je ne vois vraiment pas le problème de consensus autour du temps vraiment. Si je montre aujourd’hui une transaction daté de 2020 ça va faire consensus qu’elle n’est pas valide, car post-daté. Meme dans le monde réel ça fait un consensus absolu. Mais bon après la notion de consensus est subjective.

Dans ce cas je pense que je vais t’apprendre une chose, vu ta remarque initiale : tout choix n’est pas seulement contraint par la volonté, il l’est aussi par le temps.

L’algorithme actuel de Duniter n’est ni définitif, ni érigé au statut de “solution optimale”. C’est le mieux que j’ai trouvé dans ma fenêtre de développement pour ce logiciel.

Quant à la solution de @pparent76 telle que je l’ai comprise, elle ne me semble pas souhaitable, voilà tout.

4 Likes

Quelle est l’heure Bitcoin actuelle ? Celle-ci fait pourtant bien consensus en ce qui concerne les mineurs.

Tout dépend du référentiel dans lequel tu te places. Duniter se place dans son protocole, et faire autre chose le rendrait bancal. C’est d’ailleurs le but de tout protocole : baliser, lever les ambiguïtés, afin de pouvoir faire une chose commune. Car rien n’est évident.

2 Likes

Ok il n’y a pas de soucis, elle n’est peut-etre pas souhaitable dans Duniter, mais peut-etre souhaitable dans une autre monnaie, en tous les cas quand/si le problème de la génération du hazard est résolut.

C’est pour ça que d’autres projets attendent d’avoir un algo suffisamment prouvé pour se lancer, mais c’est un parti pris comme un autre. Se lancer permet de faire connaître l’idée de monnaie libre et de motiver d’autres gens à contribuer.

C’est en effet un parti pris, et mon rôle dans la Ğ1 était bien de la faire démarrer. Désormais chaque jour qui passe lui permet de grandir, et comme tu dis « de faire connaître l’idée ».

Mais là c’est plus qu’une idée, c’est très concret. Beaucoup ne réagissent que face à cela. Et force est de constater que jusque-là, cette stratégie a plutôt bien porté ses fruits.

Néanmoins, je le répète, le protocole est tout à fait évolutif. Nous l’avons déjà fait évoluer plusieurs fois et sommes prêts à continuer. Déjà l’algo de PoW est incorrect, la difficulté n’est pas linéaire. Il y a pas mal de choses à changer.

4 Likes

D’ailleurs je l’ai pensé comme ça : il faut démarrer. Nous pourrons changer les choses au fur et à mesure, il y a plein de gens très compétents mais il ne sont pas là à nous regarder. Faisons les venir.

3 Likes

:+1:

Et du coup, si je devais faire une proposition d’amélioration, je vous proposerais d’enlever le PoW, et de le remplacer par un tirage au sort de l’ordre des membres pour produire les blocks, et je suis sûr que la question de la manipulation du random ne devrait pas poser de pb, et que en tout cas ça sera plus sécurisé/simple/cohérent que la PoW actuelle.

D’ailleurs je précise que j’ai tendance à vennir amener des idées pour essayer de faire avancer les choses, mais ça ne veut pas dire que je critique le travail qui a été fait et qui est déja énorme, et je vous en félicite. Mais toute chose est améliorable, donc je propose des idées, après elle valent ce qu’elles valent.

Ps: je vais continuer à réfléchir à ce problème de manipulation du hazard et voir si je trouve une solution simple. Au pire il faut mettre en place ce protocole, mais c’est complexe: https://eprint.iacr.org/2012/643.pdf

Du moment que la solution s’inscrit dans le protocole (i.e. ne fait pas référence à un système externe), c’est tout bon. Algorand m’a beaucoup séduit à ce sujet, mais comme déjà dit je l’ai abandonné pour des raisons déjà évoquées.

Je suis sûr qu’il y a pléthore de solutions inexplorées applicables au réseau Duniter.

1 Like

@cgeek Tu as de la doc sur ce que tu appelles le temps bitcoin?

Comment les pairs se mettent t’il d’accord sur le fait qu’il s’est passé trop peu de temps depuis le dernier block et donc qu’il faut augmenter la difficulté, sans un “système externe” de mesure du temps?

Merci!

De mémoire, c’est une simple multiplication de la “hauteur” de la blockchain x 10 minutes à partir du timestamp#0. Cela a peut-être changé depuis, car à une époque il y avait plusieurs mois de décalage avec la date/heure “officielle”.

En fait j’ai trouvé cela:

https://en.bitcoin.it/wiki/Block_hashing_algorithm
https://en.bitcoin.it/wiki/Block_timestamp

Le header bit coin contien un “Current block timestamp as seconds since 1970-01-01T00:00 UTC”. Apparement les peers s’échangent l’heure hors blockchain “Network-adjusted time” is the median of the timestamps returned by all nodes connected to you", mais à la basent il l’obtiennent bien grace à un “système externe” de mesure du temps: l’horloge interne de leur ordinateur. Je veux dire il n’y a pas d’autre moyen de mesurer le temps, que d’avoir une montre.

D’ailleurs comment fait Duniter pour adapter la difficulté des hash pour qu’il y ai un block toute les 5 minutes. Le programme utilise bien l’horloge système à un moment ou à un autre pas vrai?

Bon enfin voilà j’ai pas envie d’insister et de prendre de votre temps. Désolé si ça a été le cas. Je vais réfléchir à mon algo de mon coté, si je trouve des choses intéressantes je vous redirait.

Bien entendu, il y a un champ Time exprès pour ça.

Mais il ne faut pas confondre : ce champ suppose que se mettre d’accord sur le temps est compliqué. Duniter laisse les calculateurs influer sur le temps blockchain, mais ne dit pas comment ces mêmes calculateurs l’obtiennent. Certains possiblement d’une horloge atomique de façon directe, allez savoir :slight_smile:

1 Like