Current block: n°207151, generated on the 2019-03-26 18:58:29
Mon nœud refuse ce bloc :
2019-03-27T09:57:05+01:00 - info: SIDE Block #207314-00000DC8 added to the blockchain in 0 ms
2019-03-27T09:57:05+01:00 - info: Block resolution: 2 potential blocks after current#207233...
2019-03-27T09:57:05+01:00 - error: Error: ruleNumber
at Function.checkBlock (/home/moul/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19)
at <anonymous>
at process._tickCallback (internal/process/next_tick.js:188:7)
2019-03-27T09:57:05+01:00 - error: Error: ruleNumber
at Function.checkBlock (/home/moul/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19)
at <anonymous>
at process._tickCallback (internal/process/next_tick.js:188:7)
2019-03-27T09:57:05+01:00 - info: Fork resolution: 98 potential block(s) found...
2019-03-27T09:57:05+01:00 - info: Fork resolution: block #207235-000000D6 is known as incorrect. Skipping.
2019-03-27T09:57:05+01:00 - info: Fork resolution: block #207235-000000D6 is known as incorrect. Skipping.
2019-03-27T09:57:06+01:00 - info: Fork resolution: block #207235-000000D6 is known as incorrect. Skipping.
2019-03-27T09:57:06+01:00 - info: Fork resolution: block #207235-000000D6 is known as incorrect. Skipping.
2019-03-27T09:57:06+01:00 - info: Fork resolution: block #207235-000000D6 is known as incorrect. Skipping.
Après un full data reset et plusieurs sync pour basculer de g1-test à la g1, mon noeud essaie encore de contacter des noeuds g1-test aussi bien que des noeud g1… j’ai fait une issue :
Aucun. Ceci dit les dossiers sont très largement répliqués sur le réseau (j’ai pu le noter hier, tant il y avait de bruit réseau quand les noeuds récupéraient la piscine d’autres noeuds et rediffusaient les enregistrements).
D’ailleurs le revert ne fonctionnera pas, c’est équivalent à la résolution de fork mais justement celle-ci échoue. Tu ne peux que resynchroniser de zéro.
Oui, je voulais attendre aujourd’hui pour le remettre sur pied. Je le fais de ce pas.
Ton nœud a forké, le mien et g1.duniter.org sont bons.
Oui, mes nœuds n’ont pas arrêté de forké depuis le début de cet incident.
Je sais pas ce qui se passe.
Deux tentatives successives de synchro sur g1.duniter.org:443 et duniter.moul.re:443 . Les deux fois, Duniter Desktop s’est fermé en cours de synchro malgré un redémarrage du PC pour la seconde synchro ? . C’est la première fois que je vois ça.
Je retente.
Edit: cette fois ça a marché en passant par “simplified mode” https://duniter.org (main mirror). C’est pourtant le même nœud g1.duniter.org:443 que j’ai rentré tout à l’heure en “manual mode” !?
Je vais finir par le savoir, mais je n’ai tout bonnement pas de créneau de concentration pour ça, et là je suis rincé, inutile. Peut-être demain soir par contre, et vendredi après-midi aussi.
En attendant, je ne peux que conseiller de tenter de synchroniser sur la branche qui avance à chaque fois qu’un fork non résolu se manifeste.
Le réseau comment à reprendre des couleurs.
Je compte 24 identités dans la fenêtre courante.
Pour autant, il n’est pas impossible que des forks se produire de nouveau.
Bon, je ne pourrais pas produire de nouvelle version ce soir, néanmoins la cause est identifiée et le bug reproductible à volonté.
La source
La cause est la résolution de fork. Plus précisément, c’est le dépilement de bloc qui détruisait des sources légitimes de monnaie depuis Duniter 1.7. La version 1.6 n’est donc pas impactée.
La destruction était systématique à chaque dépilement, créant les situations suivantes :
quand un fork naissait et que celui-ci contenait une transaction alors Duniter 1.7 était incapable de le rejoindre (car même pour rejoindre un fork, la résolution dépile ce fork au moins 1 fois pour le tester)
quand un fork naissait sans transaction mais que la branche principale contenait une transaction après le point de fork, alors Duniter 1.7 était incapable de revenir sur sa propre branche
Liens avec des événements récents de la Ğ1 et Ğ1-Test
Il y a fort à parier que ce bug soit la cause des événements déjà notifiés sur ce forum :
Ainsi que des retours d’utilisateurs depuis Janvier 2019 dont les témoignages concordent.
Ce bug est toutefois indépendant du fork de Noël 2018.
Et aussi curieux que ça puisse paraître, ce cas de résolution de fork avec transaction n’était couvert par aucun test, ce qui lui a permis de passer à travers les mailles du filet.
Correctif à venir
Demain après-midi/soir 28/03/2019.
Comportement à adopter
Seul palliatif pour l’instant :
resynchroniser sur la branche principale quand vous constatez un fork
Les RML13 “coeur de Ğ1” s’avèrent non seulement pertinentes, mais extrêmement urgentes, en tant que recentrage durable des RML sur son fondement : développer les compétences et le développement sur le coeur.
Expliquer le protocole, le détailler, l’analyser, détailler le fonctionnement, les modules, les documents d’entrée et de sortie, faire l’état de l’existant et du développement, le tout pendant 3 jours pleins, en plein centre de la Capitale des Rois de Majorque au centre ville paradisiaque, à 15 mn en voiture du bord de mer, à 45 minutes des Pyrénées…
Pour les développeurs motivés seulement, la partie coeur de Ğ1 sera dans un lieu idéal pour 10 à 15 développeurs experts voulant rejoindre le projet, ou en cours de développement (Duniter, DURS, Juniter, Silkaj, Cesium), pour travailler sur le coeur et les protocoles et documents gérés pas le coeur, comprendre la blockchain Duniter/Ğ1.
Ceci est une révolution.
Pour les non-développeurs, contactez l’équipe monnaie libre 66 qui prépare des ateliers dans d’autres lieux dans et autour de Perpignan (voir le pad des RML13 via le site officiel).
Du coup ça expliquerait pourquoi un restart a des chances de faire repartir sur la bonne branche, non ? Je viens encore d’avoir le cas sur mon raspi. Je l’ai relancé une première fois, toujours coincé. Une deuxième fois, il s’est réaligné sur la branche principale.
