Plusieurs nœuds restent bloqués sur le bloc 307383 alors qu’à l’heure où j’écris, certains sont au bloc 307606.
J’ai lu sur le forum que si un fork dure plus de 100 blocs il faut le resynchroniser manuellement.
Vous pouvez me confirmer si il doit y avoir une action à faire, ou on laisse juste passer ?
Merci d’avance.
EDIT: je me rends compte que ce sont tous les noeuds qui sont en version v1.7.21 qui sont dans ce cas
silkaj wot resp_corp
resp_corp (7DtQY…) from block #64594-000000D49…
received 4 and sent 6/100 certifications:
| received_expire | received | sent | sent_expire |
|-------------------+-------------+-------------+---------------|
| 2020-03-08 | Fouintoc ✔ | Fouintoc | 2020-04-16 |
| 2020-04-22 | AnneLaure ✔ | donazolt | 2020-04-16 |
| 2021-12-26 | Anneuh ✔ | SebasC | 2020-04-16 |
| 2022-02-03 | maksou ✔ | maksou | 2020-04-16 |
| | | vivinthesky | 2020-09-03 |
| | | Lebelen | 2021-02-09 |
✔: Certifications written into the blockchain
member: True
C’est le second cas. Du coup, je conseille aux nœuds bloqués au bloc 307382-0000024A (que des v1.7.21) de suivre la branche majoritaire la plus avancée où les < 1.7.20 sont (307507-00000AA024). Dis simplement, resynchroniser leurs nœuds sur https://g1.duniter.org
Ça devrait permettre aux nœuds en v1.7.21 de se resynchroniser sur cette branche sinon, ça viole la règle du protocole, et le nœud refuse d’aller plus loin.
Édition : j’ai réussis à synchroniser mon nœud v1.7.21 sur la branche majoritaire où resp_corp redevient et est exclus de la toile Ğ1.
Non car la sync rapide (sans l’option --cautious) ne revérifie pas touts le règles du protocole, donc même si resp_corp était toujours membre tu peut te resync en 1.7.21
Ok, surement en théorie, mais dans la pratique la synchronisation était bloqué sur ce bloc.
Je sais pas en tout cas, cette fois, après l’exclusion de resp_corp la synchro a été complétée.