Au pire, sync sur mon noeud… Il est peu chargé.
Ce n’est pas une erreur, le noeud qui essaye de se connecter a toi fourni une signature incorrecte, soit c’est les aléas réseau soit c’est un noeud menteur, soit il déclare une clé publique différente de celle avec lasquelle il signe, le problème ne viens pas de chez toi 
Oui, bien sûr, je vois tous les autres nœuds avec le bon HEAD.
Il y a aussi ça dans ma log :
2018-03-03T22:10:27+01:00 info SIDE Block #99709-0000052A added to the blockchain in 422 ms
2018-03-03T22:10:27+01:00 info Block resolution: 1 potential blocks after current#73499…
2018-03-03T22:10:28+01:00 error
2018-03-03T22:10:28+01:00 info Fork resolution: 99 potential block(s) found…
2018-03-03T22:10:34+01:00 warn WS2P: cannot connect to incoming WebSocket connection: WS2P connection timeout
2018-03-03T22:11:07+01:00 info Fork resolution: block #73500-0000041C is known as incorrect. Skipping.
Je sens qu’il y a un truc bien pourri dans mon installation. Ou dans mon serveur !
Tu n’as pas sync sur un fork ?
Non son blockstamp prouve qu’il est sur la bonne branche.
@sveyret je pense plutot a une corruption de ta bdd suite a un aléas réseau pendant la sync, la solution est de reset :
duniter reset data
duniter sync HOST PORT
2 Likes
OK, je vais essayer ça.
1 Like
J’ai vue passer la demande dans mon log.
Par contre,
2018-03-03T16:17:36-05:00 info WS2P: connection [9UuWHs3Z WS2P g1.neptura.org 20901] has been closed
C’est même certain car la sync télécharge les blocs par chunk de 250 blocs, ici c’est ton chunk 73500-73749 qui est arrivé corrompu, lles blocs de ce chunk corrumpu sont donc invalide, donc ton noeud refuse de les empiler. J’ai ouvert une issue pour ça : Sync : check integrity of downloaded chunks (#1285) · Issues · nodes / typescript / duniter · GitLab
La première fois que j’ai synchronisé, ça c’est bloqué sur ce bloc, et j’ai donc arrêté le serveur pour tenter de redémarrer. C’est peut-être ce qui a corrompu.
J’ai relancé la synchronisation, mais qu’est-ce que c’est long !
Oui il ne faut jamais arreter le serveur lorsqu’il est en cours de sync !
Oui c’est long, et ça le sera de plus en plus, mais ce n’est a faire qu’une seule et unique fois 
Il n’y a pas bien d’autre choix, tu télécharge l’intégralité de la blockchain, si ta connexion est lente ç’est forcément long, même avec toutes les optimisations du monde !
1 Like
J’ai beaucoup de ligne comme ça :
2018-03-03T16:24:57-05:00 trace WS2P >>> sendCONNECT >>> WS2P:CONNECT:g1:GjJ6EJHuiwVHSXVBpSnxMFsVeRfVvAgjSLtNXNe2joef:c3838cab-a5f5-4e2d-aa15-c53669222540c4038c8c-2733-4ca1-ab5a-6766ac26c1a6
2018-03-03T16:24:57-05:00 error WS2P >>> >>> WS ERROR: INCORRECT_PUBKEY_FOR_REMOTE
Il existe un moyen pour moi d’aider la personne ou ont assume que c’est un hack ?
Dans ton cas c’est encore autre chose, c’est ton noeud qui garde des fiches de peer obsolètes, le noeud distant a changé de clé mais a toujours le même endpoint, donc toi tu considère que la clé qu’il t’indique n’est pas celle attendue, ce problème viens du fait que les anciennes fiches de peer sont mal néttoyés et a déjà été tracker : clean old peer files and old endpoints (#1261) · Issues · nodes / typescript / duniter · GitLab
2 Likes
53%… C’est vraiment très très long !
ta connexion est pourave 
Probablement… Vivement la fibre ! 
La phase Apply utilise aussi la connexion ?
Non la phase Apply consiste a vérifier la validité de chaque bloc et a appliquer les tout evenements qui se trouvent dedans, en gros ton noeud “revie” toute l’histoire passée de la monnaie.