Réévaluations du montant du DU

La formule exacte, telle que je la lis dans le code de Duniter, est :

DU(t) = ceil_centimes( DU(t-1) + c² × ceil( M(t-1) ) / N(t) / ½ an )

Exprimée en français, c’est le DU précédent auquel on ajoute : c², multiplié par l’arrondi supérieur de la masse monétaire lors de la dernière réévaluation, divisé par le nombre de membres courant, divisé par l’intervalle entre deux réévaluations (en jours) ; le tout arrondi au centime supérieur.

Donc en fait beaucoup de formules qui circulent sont effectivement fausses. Celle de Cesium est aussi fausse (en fait, il faudrait propager les t dans chacun des membres M et N car là on pourrait croire qu’il faut multiplier M/N par (treeval-dtreeval). @kimamila

La question qui se pose peut-être est : est-ce qu’on veut plutôt garder la formule contenue dans le code de Duniter et dans le protocole, ou celle qui circule ? Car au final, ce qui est la loi, c’est ce que ceux qui font tourner des nœuds décident. :stuck_out_tongue:

Dans les deux cas, le DU va s’ajuster en fonction du nombre de membres, avec plus ou moins de retard selon qu’on prend le nombre de membres actuel ou le nombre de membres à la dernière réévaluation. Cette deuxième solution a l’avantage qu’on pourra déterminer le DU dès la réévaluation précédente, tandis que celle utilisée actuellement ne permet pas de déterminer le prochain DU à l’avance, ou en tout cas seulement peu de temps avant la prochaine réévaluation par extrapolation et prévision du nombre de membres. C’est peut-être plus rigolo, on peut même lancer des paris. :stuck_out_tongue: Dans tous les cas, ça n’a que peu voire pas d’impact du tout, vu la très faible réévaluation, tous les utilisateurs se fichent éperdument d’un petit centime d’écart à la prochaine réévaluation et ce pour encore assez longtemps a priori. Ça a un impact long terme peut-être un peu plus prononcé, mais ça reste négligeable.

Pour ma part, je changerais les clients et je garderais la formule, histoire d’avoir le moins d’impact possible au niveau des développeurs. Quant à la formule, 99,9 % des utilisateurs ne la comprennent pas de toute façon. :smiley:

3 « J'aime »

Attention le code n’est pas la loi, ce qui fait foi c’est la spécification du protocole ici, qui donne la formule suivante :

HEAD.dividend = CEIL(HEAD_1.dividend + c² * CEIL(HEAD~1.massReeval / POW(10, HEAD~1.unitbase)) / HEAD.membersCount)

C’est uniquement sur cette spécification que l’on peut se baser pour juger une formule de « juste » ou « fausse ».
Il semble que la formule dans le code de Duniter soit bien conforme a la spécification, donc c’est bien les clients qui sont en tord :slight_smile:

Pour info, j’ai édité mon message au-dessus. Pour ma part, je suis d’accord pour garder la formule telle qu’elle est codée.

ceil(1007+0.04886^2×614000000÷2229÷182.6)/100 ≃ ceil(1010.6)/100 −> 10,11 Ğ1

Je comprends pas pourquoi M(t-1) et N(t) sont utilisés.

Avec N(t-1):

ceil(1007+0.04886^2×614000000÷1742÷182.6)/100 ≃ ceil(1011.6)/100 −> 10,12 Ğ1

C’est pas la formule décrite dans la TRM et ça fausse le taux de croissance c.

En soi c’est pas si grave.

me too. Mais est ce que ça vaut le coup de modifier le protocole pour ça ?
J’ai tendance a penser comme Jytou que ce n’est pas urgent et qu’on peut laisser le protocole tel qu’il est pour le moment :slight_smile:
Après si veut qu’on en change, tu peut ouvrir un thread sur le forum technique :wink:

Une personne/association/entreprise a besoin de faire des prévisions pour ses calculs économiques :confused: Pouvoir connaître avec certitude ce genre d’informations à l’avance c’est jamais de refus !

Mais effectivement, la part relative du DU varie déjà en fonction de N au jour le jour. Que N varie juste avant ou juste après la revalorisation change pas grand chose à cela.

Ça ne fait que renforcer mon intuition que les entreprises n’utiliserons pas le DU mais plutôt la moyenne comme référentiel/unité de compte :slight_smile:

3 « J'aime »

C’est vrai, les prévisions ont leur importance, c’est pour ça que je l’ai souligné. Mais franchement, on peut d’ores et déjà prévoir avec une forte probabilité le prochain DU. Je viens de calculer l’intervalle du nombre de membres qui ferait un DU à 10,16 Ğ1 pour la prochaine réévaluation, ça se situe entre 2588 et 3235 membres dans 6 mois. Vu les progressions précédentes, on peut déjà dire aujourd’hui (6 mois à l’avance quand même) qu’il y a quand même de fortes chances que l’on soit dans cet intervalle. Plus l’échéance va se rapprocher, plus la probabilité va augmenter et il sera même probablement possible au moins un mois avant de le savoir avec certitude vu la vitesse max des certifications. :slight_smile:

2 « J'aime »

Ahah, j’avais déjà dans l’idée de générer ce tableau dans Gxtrais :stuck_out_tongue:

1 « J'aime »

Bonsoir,

Bravo @jytou pour avoir levé ce lièvre !

Je pense que maintenant que l’objet de la problématique est établit, il serait plus adéquat de discuter ce point sur forum.duniter plutôt qu’ici.

À mon sens, ça demande un correctif car on sort du cadre de la TRM. Mais l’avis de notre ami perpignanais serait à prendre en compte.

Il me semble ^^

Cordialement,

Candide

1 « J'aime »

Du coup, qu’en pense tu @Galuel ? :slight_smile:

Je pense que la formule dans Cesium est la bonne, je l’ai vérifiée minutieusement à la date où Benoît avait prévu de l’y mettre (ou que j’ai fortement suggéré de l’y mettre, peu importe !). Après ce qui est dans le code je ne sais pas, mais les premières réévaluations étaient parfaitement prévisibles.

Après d’un point de vue expérimental - pratique, la différence sera minime et sans impact majeur.

2 « J'aime »

J’ai vérifié moi-même dans le code de Duniter et @jytou a raison, la formule appliquée par Duniter n’est pas la même que dans Cesium.
Après, la différence étant minime, je préfère qu’on ne modifie pas le protocole juste pour ça, et qu’on attende une futur version majeure de protocole pour y intégrer la correction de la formule dans la foulée :slight_smile:

1 « J'aime »

Ca n’a pas de raison d’être une priorité majeure, ça ne pose pas de problème ni pratique ni théorique, on obtiendra une courbe extrêmement proche de l’autre, qui ne change qu’un delta.

1 « J'aime »

Oui, exactement, c’était exactement ce que je voulais dire par :

De manière approchée, oui, mais pas de manière exacte. Il me paraît quand même important que les formules affichées soient identiques à celle appliquée par Duniter, sinon quelqu’un qui appliquerait la formule affichée risque d’être un peu surpris… si on peut éviter les confusions, c’est mieux.

1 « J'aime »

@jytou peut tu ouvrir une issue sur le dépôt de Duniter pour tracer ce problème ? Merci :slight_smile:

Oui, je veux bien, mais que veut-on exactement ? Corriger la formule de Duniter à terme pour mettre celle de Cesium ? (et donc prendre N(t-1) et non N(t) ?) C’est la solution qui plaît le plus à l’unanimité ?

1 « J'aime »

C’est moins une question de « plaire » qu’une question de démonstration.

L’ouverture de l’issue concerne le constat d’un écart entre la formule appliquée par Duniter et celle indiquée par Cesium et le fait que la formule dans Cesium semble plus correct a plusieurs contributeurs, on pourra indiquer plus tard en commentaire de l’issue la décision prise in finé :wink:

1 « J'aime »

@jytou, oublie.
Finalement j’ai créé l’issue sur le dépôt des RFCs, les issues concernant un changements de protocole ont davantage leur place sur ce dépôt plutôt que sur le dépôt de Duniter.

Surtout qu’en l’espèce, ce n’est pas un bug de Duniter mais une erreur dans les spécifications du protocole :wink: .

L’issue est ici : https://git.duniter.org/nodes/common/doc/issues/5

4 « J'aime »

Allez, la réévaluation s’approche !

Jeu - concours

J’offre 1DU du futur (23 mars 2020) à la première personne qui répondra à cette question en détaillant le calcul :

quelle serait la valeur du DU après la réévaluation de septembre 2020, si le nombre de membres restait stable d’ici au 21 mars 2020 ?

La question est posée au 01/03 :
M = 13870147.32
N = 2584

Les devs et les personnes ayant déjà participé à ce sujet sont exclues de ce jeu-concours.

Quant à moi, j’ai fait les calculs, mais je ne suis pas tout à fait sûr du résultat :rofl: