Fork sur le bloc #307383? Entrée de resp_corp avec quatres certifications

Bonjour à tous.

Comme c’est la première fois que je le vois sur mon nœud duniter, je ne sais pas si c’est vraiment ça…
Est-ce bien un fork qui se passe ici ?


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

Ok vu la réponse sur le forum :
https://forum.duniter.org/t/nouvelle-version-1-7-21-de-duniter-hotfix-g1-test/6843/19
avec la solution venant de @Moul :

Merci

En fait, c’est pas lié à un fork de protocole étant donné qu’il faut 60-70% de calculants.
J’ai trouvé le responsable qui est re-entré hier soir avec quatre certifications :slight_smile: :

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

3 Likes

Drôle, resp_corp a été re-exclut le 22 mars au soir avec la perte de sa quatrième certification après être entré le 21 mars au soir.

|  received_expire  |  received   |    sent     |  sent_expire  |
|-------------------+-------------+-------------+---------------|
|    2020-04-22     | AnneLaure ✔ |  donazolt   |  2020-04-16   |
|    2021-12-26     |  Anneuh ✔   |  Fouintoc   |  2020-04-16   |
|    2022-02-03     |  maksou ✔   |   maksou    |  2020-04-16   |
|                   |             |   SebasC    |  2020-04-16   |
|                   |             | vivinthesky |  2020-09-03   |
|                   |             |   Lebelen   |  2021-02-09   |

Ç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.

1 Like

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.

1 Like

Hum :thinking: Un décalage lors de l’apply alors, c’est bizarre.