Certification en attente, présente en piscine

certifications

#1

J’ai envoyé une certification à @Looarn en date du 125709
L’unique et précédente certification que j’ai émise (et inscrite à la même date) est en date du 124829
124829+1440=126269
1440= 5jours x 24h x 60mn / 5mn/blocks

126269 (bloc actuel) - 126526(bloc prévue) = -257 blocks ~ 1 jours de décalage entre la date “prévue” et la date effective d’inscription.

Ais-je manqué quelque chose ou n’ais-je pas bien compris la règle d’attente / inscription en block ?
D’ailleurs en passant, la règle d’émission de blocks > 5jours, c’est implémenté en 5j calendaire ou en blockdate ? :yum:

Merci


#2

Envoyée depuis cesium ?


#3

Yes je ne maîtrise pas encore assez silkaj :wink:


#4

J’ai produit un bloc 126531 vide de données
avec la certification attendue dans ma piscine, “block_hash” de la certif : 000004483166A5216BF2B12CF539AD6BD3066191F853CD7912D04A60AB078C5B

Normalement, la certification “aurait” dû passer à partir du bloc 126526, de ce que j’ai compris des règles ?


#5

Est ce bien le bon noeud qui a produit le bloc ? (celui qui avait l’info en piscine ?)


#6

Yes il ne me reste qu’un noeud à produire :wink:


#7

Toutes les durées dans Duniter sont nécessairement mesurée dans la métrique “temps blockchain” qui est définie comme la moyenne du champ time des 24 derniers blocs, on ne s’embêterai pas a définir un temps blockchain pour ensuite ne pas s’en servir.

Il conviens de rappeler que le membre qui trouve un bloc est libre d’indiquer la valeur qu’il veut dans le champ time de son bloc, il est impossible de vérifier s’il triche ou pas. En plus chacun a son propre temps (relativité générale), et de toute façon même sans tricher toutes les machines ne sont pas régler a la même heure UTC a la seconde près.

Bref il vaut bien définir un temps commun afin d’éviter que certains membres n’essayent de fausser le temps de la monnaie et donc fausser le rythme de création des DU et donc modifier la valeur de c. Or la valeur de c est la seule différence entre une vraie monnaie et une monnaie de test.

Ta certif @aguy sera inscrite dans le premier bloc dont le champ median_time dépassera la valeur chainable_on de ta certif précédente dans la base de donnée :wink:


#8

Merci pour ta réponse @elois
J’ai bien identifié la transaction correspondante à la certification dans les tables au block 125709

  • “certifications_pending” champs: from / to / block_number
  • “cert” champs: from / to / block_number

mais en recherchant la valeur pour chainable_on dans la table “c_index” pour moi en tant qu’ issuer -> nothing ??

La seule donnée me concernant en tant qu’issuer est la certification adressée à Grall cyril, qui a été inscrite dans la blockchain au block 124829 ?
Données qui auraient dû supprimées à la synchro de mon noeud au block 124829 ?

Il n’y aurait pas eu un bug entre les 2 certfis ?

Merci pour toute aide :wink:


#9

@aguy, j’ai trouver le problème : ta certif pointe un blockstamp invalide, il faut que tu la réémette.

En effet le blockstamp de ta certif est 125709-000004483166A5216BF2B12CF539AD6BD3066191F853CD7912D04A60AB078C5B

or en blockchain c’est 125709-0000029492798BFD89845BC6683650AEB9A031EC7F99906600A2F2E2D52FC982

donc elle ne sera jamais écrite et sera supprimée au bout de 2 mois.

Ce la signifie que tu a émis ta certif pendant un fork, et le noeud ed référence de ton cesium était sur la branche devenue minoritaire. C’est le même problème que pour les TX pour lequel des solutions sont en discussion ici : Cesium: Transactions référencant un bloc incertain (dont l’age < 6 blocs)

Quoi qu’il en soi, c’est un problème coté Client. Aucun bug coté Duniter ici :slight_smile:


#10

Un utilisateur qui explore la BDD pour vérifier ce qu’on lui dit ? J’aime !


#11

Yep mais en 1.7 il ne pourra plus :laughing:


#12

Ok, merci à tous :hugs:


#13

Mais si, elle sera exportable !