C’set la “date” de signature. Pour faire référence à une date du passé, on fait référence à un block existant dans la chaine.
Il est possible que la certif précédente pointait sur un block d’un fork, et dans ce cas elle ne pouvait pas être acceptée sur la chaine qui a fait consensus.
Donc, la première certification a été perdue dans la tourmente du fork. C’est un processus normal dans le fonctionnement d’une blockchain, avec, en général, un effet limité. Et elle a été renouvelée un peu plus tard. Comme quoi la promesse d’une certification est plus importante que la certification elle-même. Sur le reste, Inso a déjà répondu.
@inso
Effectivement, l’ancienne certif portait une date “block” 123037 qui était supérieur à la date du fork 123034, ce qui semble confirmé ton analyse 
Pour les certifs ce n’est pas gênant mais pour les transactions c’est gênant, pour éviter ce problème de transactions dont le blockcstamp deviendrais invalide suite a un fork, il suffirai que les clients choississent un blockstamp de 3 jours dans le passé par exemple, la fenêtre d’écriture étant de 1 semaine, la transaction resterai avec un blockstamp valable.
Certaines certifications émises pendant le fork et notamment dimanche vont se retrouver invalides et ne seront donc pas écrites, alors qu’avec un blockstamp a j-3 ça serait passé. Bien sur ça ne résout le problème que si le fork dure moins de 3 jours, ce qui a toujours été le cas jusqu’a présent 
Bon, elle n’est toujours pas fini la synchro.
Ok, mais elle en est où ?
Ça y est. C’est de retour.
On peut avoir le détail du pourquoi ça dur “aussi longtemps” de résoudre le fork ?
Pour faire le parallèle avec bitcoin les forks (devenu très rare) dur en moyenne 1 bloc, on comprend l’importance de l’incentive économique qui n’existe vraisemblablement pas sur duniter, mais n’avons nous pas un moyen d’améliorer la résolution coté noeuds ? @cgeek @elois ?
Dans la pratique les fork ne durent pas très longtemps dans Duniter non plus. Aujourd’hui, les noeuds rejoignent un fork qui a 30 minute d’avance sur eux (avec un block toute les 5 min ça fait 6 blocks en moyenne). Mais si le réseau se split bien (à 50/50), les 2 branches peuvent avancer presque à la même vitesse et ça peut mettre un peu de temps à résoudre. Mais ça dure rarement au delà de 6 blocks quand même. Il faudrait un outils de monitoring des forks, on ne les voit pas toujours…
Ca t’évoque des idées pour améliorer ça ?
@Looarn dans le cas présent ce n’est pas un simple fork réseau, mais un fork réseau couplé d’un bug qui faisaient que les nœuds sur la branche perdante n’arrivent pas a roll back… il faut donc que tout les noeuds sur la branche perdante soit resynchroniser manuellement !
Comme le dit @Inso, hors-bug les fork se résolvent rapidement.
Can you define “rapidement”? 
Ben là sans application de monitoring, je ne saurais te dire 
Mais on n’a jamais été gêné par un fork long (à l’exception des forks bloqués à cause de bugs sur le code des noeuds)
Si la branche qui vas le plus loin dépassé de 3 blocs et 15 min ma branche courante, alors je roll back et j’empile sur cette branche.
En théorie le temps maximal est donc infini si deux branches avancent a la même vitesse, en pratique ça prend souvent moins de 30 min.
Salut, j’ai lu que tu avais gardé les fichiers sqlite du fork sur l’un de tes 2 serveurs, te serait-il possible d’en faire un export à partir du block concerné 123034 afin de pouvoir aider les personnes qui ont eu des transactions perdues comme RONCORONI Pascale afin de leur permettre de redemander des paiements perdus ?
Ben en fait, les noeuds Elasticsearch g1.data.duniter.fr indexe le noeud Duniter g1.duniter.org:443
Donc si l’un est dé-synchronisé, l’autre l’est aussi !
Attention ! Avec la resynchro, plein d’inscriptions en piscine ont été supprimées du noeud g1.duniter.org 
Cf la différence entre ici et ici
aie aie aie !
Ne serais-ce pas utile de fraire un carwling sur les piscines du réseau ?
Je vois 129 dossiers en attentes de chaque côté. Quelle est la différence ?
Je vois pas cette demande d’adhésion dans la liste « inscriptions en attente »
Bizarre
A part avoir une trace des documents, cela n’aurait de toute façon servi à rien : soit les certifications/identités/adhésions étaient valides et ont alors été répliquées sur tout le réseau, soit elles ne l’étaient pas et il fallait alors tout refaire.
Au final je suis assez “content” de cet incident, ça va peut-être faire bouger des contributeurs pour Cesium dont la notoriété mérite que son code soit davantage maintenu, et pas seulement par 1 seule personne. C’est pareil pour Duniter, sans les nombreux contributeurs le logiciel n’en serait pas là aujourd’hui.
Certes Duniter aurait pu éviter ce fork de longue durée, les nœuds ayant forké n’auraient pas dus être bloqués aussi longtemps. Mais qu’en sera-t-il demain quand il s’agira d’un nœud corrompu qui donnera sciemment de fausses informations pour tromper les utilisateurs ?
Je confirme que depuis que ça remarche, je suis obligé de re-syncroniser manuellement mon raspberry environ deux fois par jour. C’est chiant.