Pourquoi boyeshua n'entre-t-il pas?

Selon WotWizard et g1-monit, boyeshua aurait dû entrer dans la TdC le 07/12/2020 à 13:02:28, mais ce n’est pas encore le cas.

2 J'aimes

Je n’ai pas investigué mais voici l’hypothèse la plus probable :

boyeshua respecte la règle de distance avec ses 7 certif mais pas avec les 5 qui sont disponibles actuellement.

g1-monit prend en compte toutes les certif pour calculer la règle de distance, que ces certif soit dispo ou pas.

3 J'aimes

Merci pour ta réponse. Je ne savais pas pour g1-monit, c’est intéressant à noter.
Toutefois, l’argument ne tient pas dans le cas de WotWizard, qui calcule le nombre minimal de certificateurs (>= 5) pour que la règle de distance tienne. Ici, il calcule bien 5. On peut d’ailleurs vérifier que la qualité de la cinquième certificatrice (Aude49) est de 1,06 (84.94%).

2 J'aimes

Je vois que sur mon noeud membre par exemple je n’ai pas les certif de BenoitLeBars et Francisco, donc il ne peut pas inscrire boyeshua dans un bloc puisque seulement 3 certif de dispo.

Il semble que certaines certif ait été mal diffusée au réseau, l’explication est très probablement là.

3 J'aimes

Je vois toujours ‹ boyeshua › dans monit ‹ future-membres ›

est-ce qu’il y a un indication d’une problemme de la distance sur le bma uri /wot/requirements/boyeshua ou le resultat: identities[0][‹ outdistanced ›] = true?

Concernant les qualités des certifieurs/certifieuses de boyeshua… j’ai joué cette semaine sur mon propre script qui calcule les distances et j’ai la suivante pour eux.

FrancoiseEpiard is sentinel: True
sentinels reached after 5 steps: 1719/1866 92.12%
sentinels reached via cert sent: 1018/1867 54.53% quality: 0.68

Floalchimistefee is sentinel: True
sentinels reached after 5 steps: 1745/1866 93.52%
sentinels reached via cert sent: 1113/1867 59.61% quality: 0.75

BenoitLeBars is sentinel: True
sentinels reached after 5 steps: 1631/1866 87.41%
sentinels reached via cert sent: 780/1867 41.78% quality: 0.52

Francisco is sentinel: True
sentinels reached after 5 steps: 1785/1866 95.66%
sentinels reached via cert sent: 1273/1867 68.18% quality: 0.85

Aude49 is sentinel: True
sentinels reached after 5 steps: 1825/1866 97.80%
sentinels reached via cert sent: 1587/1867 85.00% quality: 1.06

En utilisant mon noeud (bma /wot/requirements/boyeshua), j’ai reussi recreer le « Identity » doc, « Membership » doc, et les 5 « Certification » docs, toutes signées et verifiable… avec l’intention de chercher les noeuds qui n’ont pas les docs et de tous re-publier (mon noeud me donne « Already up to date ») mais pas la penne si le regle-de-distance est la vraie problemme. boyeshua_signed_docs.txt (3,3 Ko)

-Spencer971

ajouté: Je suis entrain de regarder /wot/requirements/boyeshua sur des noeuds publiques. Je vais assumer que les autres ont la meme que le mien (un dosier avec identité, membership, et 5 certs dispos… et aussi outdistanced=true). Mais je viens de voir qu’au moins un noeud, bien a l’heure, n’a pas la meme valeur de ‹ outdistanced ›. Je commence avec ma liste en suite:

  • g1 e-is pro (outdistanced=false, duniter-ver=1.7.21)
  • g1 guenoel fr (Membership et 4-Certification manquant… je les ai publiées)
  • duniter normandie-libre fr (1-Certification manquant… je l’ai publiée)
  • g1 bourdon eu org (1-Certification n’est pas encore dispo car ce noeud n’est pas a l’heure #379633)

J’ai fini d’inspecter le bma /wot/requirements/boyeshua sur (approx.) 20 noeuds publiques, et pour le plupart, ils ont tous « outdistanced=true » avec les 5 certs dispo… sauf un a outdistanced=false (g1 e-is pro qui utilise duniter v.1.7.21). on vera… mais je suis perdu pourquoi ce compte ne respecte pas le regle-de-distance… a mon comprehension, le dosier est pret d’etre ecrit.

a noter: si je comprends bien le regle-de-distance et le regle qui decide les ‹ referents › / sentinels… on arrivera bientot avec 3125 membres… et les ‹ referents › vont avoir besoin de 6 certifs recus et 6 certifs envoyés. ceil(pow(3125, 1/5)) == 6.

Cause connue et pas résolvable :

Mais je rappelle que les noeuds Duniter 1.7.x ne doivent plus être utilisés. Je maintiens uniquement la dernière version stable de Duniter (1.8 actuellement).

1 J'aime

Je rappelle que pour l’instant seules les versions 1.7.x peuvent faire tourner WotWizard et sont donc indispensables. Vivement GVA.

1 J'aime

Bloc: 380660 Temps réel de la chaîne de blocs: 10/12/2020 20:48:16 Temps médian de la chaîne de blocs: 10/12/2020 19:33:42

Entrée de boyeshua
2866 

C’était bien un problème de diffusion de données.

2 J'aimes

je ne suis pas convincu… mais j’avoue que je ne comprends pas la meme regle de distance que duniter exprime.

Hier j’ai regardé sur au moins 20 d’autres noeuds (/wot/requirements/boyeshua), le plupart ont eu l’identité, adhesion, et 5 certifs dispo (sans eric), ils ont tous eu « outdistanced=true », meme avec un dosier complet pour boyeshua, inclusif de certification d’Aude49 qui donne toute seul le chemin necessaire pour boyeshua de reussir le regle de distance.

Je reste sur mon avis que wotwizzard, monit, et meme mon propre script wot_distances.py comprennent une version de regle de distance qui et different que l’un que duniter v1.8.0 utilise.

Spencer971

en anglais pour vous qui n’appreciez pas mes effforts francais:

I checked many nodes yesterday using the bma /wot/requirements/boyeshua and most of them had completed suite of docs for boyeshua (Identity, Membership, and 5 available certifications… only Aude49 completed, all by herself, the distance rule for boyeshua). A few didnt have completed suites, but I posted these missing docs to those nodes individually so that they were up to date. All duniter v1.8.0 nodes with complete dosiers still showed « outdistanced=true ».

I believe that wotwizard, monit, and even my new script (built to mimic monit) have a different idea of the distance rule than is used by duniter v1.8.0… but I have no clue what that difference is.

1 J'aime

I don’t understand why the number of sentries is not the same in both calculations 1866 <-> 1867.

ceil(pow(3125, 1/5)) = 5
ceil(pow(3126, 1/5)) = 6

1 J'aime

because FrancoisEpiard is a sentinel… he reaches himself without any step… and is ignored in his own totals after 5 steps.

The second line is to represent quality… how far would a future member reach with only this member’s sent certificate. In this case, the certifying member is the first step from the future member, and is counted in total sentinels reached… nothing is ignored because it’s really about how many OTHER sentinels can one reach in 5 steps.

I may be completely confused… but that is what Im trying to express in https://git.duniter.org/spencer/learn-g1/-/blob/master/wot_distances.py

I may be wrong, but I don’t think so.

1 J'aime

as far as calculations for « how to determin necessary sent/received certs for a sentinel/sentry »: I get the following:

$ python
Python 3.8.5 (default, Jul 28 2020, 12:59:40)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import ceil
>>> ceil(pow(3124, 1/5))
5
>>> ceil(pow(3125, 1/5))
6
>>> ceil(pow(3126, 1/5))
6

It looks like a rounding error, since 5^5 = 3125. Making the calculus with whole numbers is better.

1 J'aime

I totally agree… and this is going to bother me all day, perhaps all weekend. GUIDO!!!

sentinel_threshold = ceil(log(members, stepMax)) perhaps better???

$ python
Python 3.8.5 (default, Jul 28 2020, 12:59:40) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import ceil, log
>>> for members in [3124, 3125, 3126]:
...     ceil(pow(members, 1/5))
...     ceil(log(members, 5))
...     ceil(pow(members, 1/5)) == ceil(log(members, 5))
... 
5
5
True
6
5
False
6
6
True

granted, I cannot recall using python’s pow() or ** with fractions in the past… but I will certainly remember this in the future. :frowning:

>>> pow(3125, 1/5)
5.000000000000001

It’s a rounding problem… maybe this can help:

>>> ceil(int(pow(3125, 1/5)*1000)/1000)
5

however I don’t know if dividing by 1000 is binary-rounding safe.

2 J'aimes
func threshold (m int) int
  n <- 0
  loop
    n <- n + 1
    p <- n * n
    p <- p * p * n
    if p >= m
      return n
    endif
  endloop
1 J'aime

Monit utilise directement le code de Duniter pour calculer la distance, donc il ne peut pas y avoir d’écart possible avec Duniter.

Le code de calcul de la distance est la : https://git.duniter.org/nodes/typescript/duniter/-/blob/dev/rust-libs/dubp-wot/src/operations/distance.rs#L93-157

Et le calcul de sentry_requirement ce fait encore en js ici : https://git.duniter.org/nodes/typescript/duniter/-/blob/dev/app/lib/indexer.ts#L2500

1 J'aime