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 ?
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 ?
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
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 ?
@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
