Je ne pense pas avoir le temps ce soir d’étudier le “comment on fait à la main”, demain j’espère (noob inside, installation facile avec Yunohost mais la mise à jour manuelle faudra que je voie comment ça marche ; je devrais y arriver, c’est juste que je dois prendre le temps de le faire, c’est tout)
A suivre très vite !
sqk
edit : j’ai tenté vite fait, installation du package .deb… et ça a marché, j’ai juste dû faire un coup de duniter webstart sinon nginx me sortait une erreur 502 à la connexion au noeud. Ouf!
Je pense que ça avance toujours, mais très lentement. Il y a plusieurs forks en cours, ce qui divise la puissance de calcul et rend plus long l’arrivée de nouveaux blocs.
Sur la branche de hacky, vincentux, mmpio et Jean-F, il n’y a plus que vincentux qui peut calculer le prochain bloc #37394 (difficulté personnalisée oblige), d’où la lenteur.
Quand ce bloc sera calculé, ce sera mmpio qui pourra calculer le #37395. Mais déjà, les noeuds de cgeek et pafzedog auront rejoint le fork depuis le bloc #37394, et donc on aura en permanence 3 calculateurs, ce qui débloquera tout.
Mais en attendant, on peut soit patienter, soit ajouter/modifier son noeud sur la branche qu’on souhaite faire avancer afin d’accélérer le mouvement.
edit : voilà, le bloc #39794 a été trouvé par vincentux, je vois pafzedog qui rejoint cette branche, ainsi que nay4. Les autres devraient suivre.
Exactement ! Plus il y a de noeuds, et plus les forks sont non seulement difficiles à réaliser, mais aussi plus difficile à faire perdurer.
Passons aussi sur le fait qu’avoir son propre noeud est la meilleur garantie que ses propres documents (transactions, certifications, …) passent en priorité.
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
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)
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
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.
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
vincentux a gagné.
(pour une difficulté identique) 
