le stock de 100 certifs me parait redondant.
si une certif est émise tout les J jours et qu’elle expire au bout de E jours alors une limite naturel s’installe E/J
365*2 / 5 = 146 qui me semble être proche de 100.
tout ca n’est pas bien grave mais cette limite est-elle vraiment utile ? La solution la plus simple n’est-elle pas la meilleure?
Ça offre un paramètre sur lequel on peu jouer plus tard.
Et je trouve la différence 100 146 assez grande pour justifier cette limite.
Le panier de 100 certif est totalement arbitraire.
Pourquoi ajouter un paramètre en plus, là ou jouer sur le paramètre du délais entre les certifs suffirait ? 
Je suis aussi pour un simplification du protocole.
Je vais peut être dire une bêtise, mais le “100 certifs” c’est pas le nombre de certif qu’une personne peut envoyer dans la pool de certifs ?
C’est pas pour empêcher d’encombrer inutilement la blockchain, comme envoyer une certif à tout les membres ?
C’est pas redondant. Limiter à 100 (qui n’est pas un nombre au hasard, mais est tirée du double de la moyenne empirique connue en sciences sociales = 50), tout en proposant 5 jours entre les certifications, n’est pas équivalent à donner 365*2 / 100 = 7,3 jours entre les certifications.
Si on avait donné 7,3 jours entre les certifications, le nombre de 100 n’aurait pu être atteint qu’en certifiant effectivement tous les 7,3 jours, en espérant que ça passe à chaque fois. En donnant une limite plus basse de 5 jours, on rend la possibilité d’atteindre les 100 certifications effectives.
tu peux développer ?
en moyenne les gens connaissent 50 personnes ? de quelle moyenne empirique parles-tu?
Je ne vois pas trop ce que le double d’une moyenne signifie. je sais en revanche que les gaussienne s’en écartent. étant donné qu’il y a une borne maximale et une borne minimal naturel. je persistes à trouver cela inutile mais peut être qu’il reste ici ou la une explication… un graphique réalisé lors de l’analyse qui représente l’effet de cette variable.
je ne suis pas en faveur des 7 jours mais plutôt des 146 certifications et de l’abrogation d’une loi liberticide sur le stocks de certifs 
bien que cela ne concerne pas grand monde il existe des gens pour qui cette liberté à un sens
Quand j’arrondis 1,46 je tombe sur 1 donc pour moi c’est très proche, le même ordre de grandeur c’est proche alors l’arrondi …
46 pourcent de plus, c’est proche ?
Sachant que la constante 100 signifie X * 2, que je ne comprends pas X, que 2 semble pris à la louche, louche, qui pourrait être de 2,92, à moins que X ne vale 73
Je pointe 46% pour m’en moquer, c’est l’existence même de X qui m’interroge.
Sachant que
l’utilisation d’une constante doit être justifié, pas simplement admise
Et que
j’accepte les constantes que je comprends plus facilement
je reformule ma question
Qui et qu’elle analyse préalable fut fait pour déterminer l’usage de cette constante ?
les gens dont l’intuition fut “les certifs doivent être limité” avait-ils pris conscience que cela était déjà le cas lorsqu’ils ajoutaient de l’arbitraire dans le système?
Le paramètre sigStock dont il est question ici a une influence sur l’ampleur des attaques sybil. Plus sigStock est grand plus une attaque sybil peut être massive, c’est pourquoi par sécurité il est bon de minimiser sigStock autant que possible.
Oui la preuve ici : Étude de la WoT
Personnellement j’avais signalé que 100 me semblais trop élevé, et qu’il faudrait diminuer a 80 voir 70.
L’avenir nous dira ce qu’il en est, nous devons suivre un maximum d’indicateurs sur la santé de la wot afin de pouvoir réagir et ajuster certains paramètres si l’on pense que cela peut consolider la wot.
En revanche, il ne me semble pas souhaitable de supprimer sigStock pour que la limite devienne de fait sigValidity / sigPeriod. Cela créer un couplage fort entre des paramètres qui ont des objectifs fonctionnels très différents.
Si a l’avenir on doit modifier sigValidity ou sigPeriod pour une raison X ou Y, on sera bien content que ça n’est pas d’impact direct sur sigStock, car cet impact pourrait etre contraire a l’effet souhaité.
Exemple : Pour une raison X ou Y on augmente sigValidity, ce qui rend l’engagement de certification plus fort et donne plus de poids a cet acte, qui sera donc moins fait a la légère, et qui consolide donc la toile. Si l’on a plus sigStock, on se retrouve avec un rapport sigValidity / sigPeriod qui augmente, ce qui fragilise la toile alors qu’on augmentais sigValidity pour la consolidée.
Ce n’est qu’un exemple pour montrer qu’il existe au moins 1 cas de future évolution possible des paramètres pour lequel un couplage fort serait nuisible.
Or, on ne peut pas déterminer toutes les Ğsituations a l’avenir et les décisions que nous ou nos prédécesseurs devront prendre en conséquence.
Afin d’être le plus robuste et souple possible, évitons au maximum les couplages que l’on peut éviter