Et non, connexion hyper stable.
Pareil avec duniter.org, ETIMEDOUT au bout de 37% …
Je verse une p’tite larmichette pour mon premier bloc calculé… Merci le fork de me simplifier la tâche, si ça se trouve c’est à cause de moi qu’on est à la bourre sur cette branche 
1 Like
Hello, DSL avec mes questions, mais je cherche un peu à comprendre.
J’ai mon noeud duniter qui a 441 blocs de retard. Si il c’est arrêter d’accepter les nouveaux blocs des autres c’est qu’il y a du avoir un fork. probablement 2 noeuds qui on trouvés la PoW en même temps sur le réseau sauf que mon noeud n’a pas choisi la branche qui a finalement émergé.
Par contre comment ce fait-il que 441 block plus tard sur l’autre branche, mon noeud ne se pose toujours pas la question de la rejoindre (c’est bien la version de la blockchain la plus longue qui gagne normalement non?)
pour info mon noeud bloque depuis 2 jours sur la fonction “checkActives”:
2016-09-13T09:56:51+02:00 - info: SWITCH: get side chain #37828-00001AD96353293D2B7BCE099EF39286A15302BA24F19475F334B573529745FB…
2016-09-13T09:56:51+02:00 - info: SWITCH: revert main chain to block #37728…
2016-09-13T09:56:54+02:00 - info: SWITCH: apply side chain #37828-00001AD96353293D2B7BCE099EF39286A15302BA24F19475F334B573529745FB…
2016-09-13T09:57:00+02:00 - warn: SWITCH: error Error: Membership’s number must be greater than last membership of the pubkey
at Error (native)
at /opt/duniter/sources/app/lib/rules/global_rules.js:353:15
at next (native)
at onFulfilled (/opt/duniter/sources/node_modules/co/index.js:65:19)
at process._tickCallback (node.js:412:9)
Merci pour vos lumières 
1 Like
Toutes tes réflexions sont correctes, il y a bien un bug concernant le rebranchement sur le fork principal.
D’ailleurs tu le vois : en tentant d’appliquer un des blocs du fork principal, il rencontre un problème avec la règle concernant les adhésions, qui dit qu’on ne peut pas écrire une adhésion qui précéderait en termes de date la dernière inscrite en blockchain.
Pourquoi le fork principal tenterait une telle opération ? En réalité il ne tente rien d’anormal, comme nous avons pu le constater avec Moul. Tout va bien sur la branche principale.
Le problème (diagnostiqué ce matin) vient en réalité du code qui dépile les blocs du fork local avant de se rebrancher sur le fork principal, car cette opération, l’équivalent d’un revert Git mais pour la blockchain, est buguée concernant les adhésions. Le code tente d’oublier justement cette “dernière adhésion inscrite” pour reprendre celle qui la précédait en blockchain et plante lamentablement 
D’où coup la base de donnée conserve comme dernière adhésion celle qui aurait dû être dépilée avec son bloc, et lors de l’ajout du bloc de la branche principale qui essaye justement de réinscrire cette adhésion dans un de ses blocs, alors la règle susmentionnée concernant les adhésion est froidement appliquée et renvoie une erreur !
Maintenant, il ne me reste plus qu’à :
- Ecrire un Test Unitaire reproduisant le bug (presque fini)
- Corriger le bug et vérifier que le TU passe
- Produire une nouvelle version
- Demander aux possesseurs de noeuds de faire une RAZ de leur noeud (données uniquement), et de se resynchroniser sur la branche principale
Voilà, tu avais bien mérité ce petit laïus !
3 Likes
Si le RAZ est fait par tous les noeuds en même temps, il se passe quoi !?
Plus de monnaie
Sauf que bon, on a des miroirs de partout qui se souviennent … et ont l’intégralité de la blockchain en copie.
Cool, merci du retour
du coup j’ai fait un violent return true; sur la fonction "checkActives"
et mon nœud est bien en train de rejoindre la chaine principale.
j’avais hésité à le faire avant et remonter le bug mais je me suis dit que j’avais peut-être loupé un truc.
Merci pour tout
En voilà un qui met les mains dans le cambouis
Pour les curieux, voici le correctif et son test unitaire.
1 Like
Super, efficace le cgeek ! 
Par contre, je trouve qu’il y a beaucoup de fork sur la blockchain (alors qu’il y a peu de noeud)
cela ne serait pas dû au fait que tu pars d’un Nonce de 0 qui est incrémenté, et cela sur chacun des noeuds. du coup tous les noeuds réalisent les mêmes hash au même moment (et donc plusieurs noeuds trouve la solution plus ou moins simultanément)
Ne serait-il pas mieux de prendre un nombre aléatoire entre 0 et max(Nonce) ?
du coup moi je décrémente le nonce comme ça j’ai plus de chance de trouver avant les autres 
(pour une difficulté identique) un block avec un nonce de 9997962 
Bien tenté, mais comme il y a le champ Issuer et que celui-ci est propre à chaque membre, personne ne calcule le même bloc !
ha oué bien vu 
j’ai raté une occasion de me taire 