Appel à contributions pour Ğ1-Test

Mon noeud est à présent au bloc 40980 et reste bloqué (c’est le même que le 40980 de ton noeud pourtant).

2017-08-28T07:36:56+02:00 - warn: Pulling not finished after 10000 ms, continue PoW
2017-08-28T07:37:06+02:00 - info: Pulling blocks from the network...
2017-08-28T07:37:06+02:00 - info: Blocks were not applied.
2017-08-28T07:37:07+02:00 - info: Blocks were not applied.
2017-08-28T07:37:07+02:00 - info: Blocks were not applied.
2017-08-28T07:37:07+02:00 - info: Blocks were not applied.
2017-08-28T07:37:07+02:00 - info: Block resolution: 3 potential blocks after current#40980...
2017-08-28T07:37:07+02:00 - error:  Error: ruleMedianTime
    at Error (native)
    at Function.<anonymous> (/opt/gtest/duniter/app/lib/blockchain/DuniterBlockchain.js:74:23)
    at next (native)
    at fulfilled (/opt/gtest/duniter/app/lib/blockchain/DuniterBlockchain.js:4:58)
2017-08-28T07:37:07+02:00 - error:  Error: ruleMedianTime
    at Error (native)
    at Function.<anonymous> (/opt/gtest/duniter/app/lib/blockchain/DuniterBlockchain.js:74:23)
    at next (native)
    at fulfilled (/opt/gtest/duniter/app/lib/blockchain/DuniterBlockchain.js:4:58)
2017-08-28T07:37:07+02:00 - error:  Error: ruleMembershipPeriod
    at Error (native)
    at Function.<anonymous> (/opt/gtest/duniter/app/lib/blockchain/DuniterBlockchain.js:101:23)
    at next (native)
    at fulfilled (/opt/gtest/duniter/app/lib/blockchain/DuniterBlockchain.js:4:58)
2017-08-28T07:37:07+02:00 - info: Fork resolution: 50 potential block(s) found...
2017-08-28T07:37:07+02:00 - info: Fork resolution: 3 potential suite(s) found...
2017-08-28T07:37:07+02:00 - info: Fork resolution: HEAD = block#40980
2017-08-28T07:37:07+02:00 - info: Fork resolution: suite 1/3 (-> #41030-000271) revert to fork point block#40980
2017-08-28T07:37:07+02:00 - info: Fork resolution: suite 1/3 REFUSED block#40981: ruleMembershipPeriod
2017-08-28T07:37:07+02:00 - info: Fork resolution: suite 2/3 (-> #40983-00008D) revert to fork point block#40980
2017-08-28T07:37:07+02:00 - info: Fork resolution: suite 2/3 REFUSED block#40981: ruleMedianTime
2017-08-28T07:37:07+02:00 - info: Fork resolution: suite 3/3 (-> #40983-000078) revert to fork point block#40980
2017-08-28T07:37:07+02:00 - info: Fork resolution: suite 3/3 REFUSED block#40981: ruleMedianTime
2017-08-28T07:37:07+02:00 - info: Will pull blocks from the network in 0 min 20 sec

Si je relance le sync sans reset, je reset bloqué au 40980.

Ce matin ma vue de Duniter est la même qu’hier soir, toujours au block 41008. Avant d’installer la 1.5.8 j’avais aussi supprimé le dossier .config. Je pige pas tout mais si je peux aider n’hésitez pas. Au cas où, je vais passer Sakia sur G1-test.

J’ai tenté de config Sakia pour G1-test mais c’est loupé. Au moins, maintenant, je sais comment faire :grinning: . Bon, je vais suivre vos posts pour voir si, à un moment, je peux aider à mon niveau. Bravo pour votre implication ! :expressionless:

Je commence à entrevoir pourquoi les nœuds se comportent ainsi. Je vous dois bien des explications.

Résumons déjà qu’il existe ici :

  • le fork A (blockchain principale bloquée, protocole le plus récent), bloc courant #41009
  • le fork B (blockchain historique, vieux protocole bugué), bloc courant #43800

Tout d’abord il y a eu deux bugs :

  • le #1087 où le nœud passait un temps faramineux à résoudre ses forks, du fait que le fork B était beaucoup plus long que A, ce qui l’empêchait de démarrer un nouveau calcul de bloc. Et à chaque bloc de B qui arrivait (car cette branche vit sa vie), la résolution de fork était redéclenchée.
    Corrigé par Duniter 1.5.6

  • puis le possible #1089, où le nœud ne calculait pas le bon bloc.
    Corrigé par Duniter 1.5.7

Puis un troisième :

  • le #1091suite à une synchro la fenêtre de fork théorique pour le nœud est trop grande par rapport à sa fenêtre effective, dans la base de données. C’est un bug qui s’est révélé dès lors que je vous ai demandé de faire une synchro !
    Corrigé par Duniter 1.5.8

    Explication : quand on se synchronise sur le fork A, et étant donné notre fenêtre de fork (variable forkWindowSize) de 100 blocs (tous les nœuds ont cette configuration), alors on s’autorise à foker sur B tant que le point de fork est <= (41009 - 100 = 40909). Ce qui est le cas ici : le point de fork est au bloc #40980.

    Lorsque notre nœud tente de switcher sur B, il dépile ses blocs #41009#40981. Très bien. Puis il tente d’appliquer le fork B mais échoue, celui-ci ayant un contenu invalide (blocs respectant le vieux protocole, incompatible avec notre nœud récent).

    Et le problème, c’est que lorsqu’on tente de rempiler nos blocs précédemment dépilés, le nœud échoue ! Ce qui est un bug manifeste, puisque ces blocs s’empilaient très bien avant, à la synchro.

    La cause ? En mode “synchro”, l’empilement se faisait en mode accéléré, et la fenêtre effective, c’est-à-dire les blocs présents dans la table b_index, n’étaient que de une seule entrée ! Au lieu des 100 requises a minima. Et dans ce cas le nœud part en cacahuète.

Maintenant, les autres bugs que je découvre :

  • le bug #1091 est mal corrigé, car finalement je n’ai pas 100 blocs présents dans b_index, mais seulement une soixante-dizaine. Au final, pour être vraiment tout à fait précis, lors d’une synchro dont le HEAD distant est H, il m’en faudrait exactement :

    forkWindowSize + MAX(
       block(H.number - forkWindowSize).issuersCount,
       block(H.number - forkWindowSize).issuersFrame,
       medianTimeBlocks,
       dtDiffEval
    )
    

    Soit à ce jour dans Ğ1-Test, 126. C’est peut-être gênant ici avec Ğ1-Test dans un cas que j’ignore.

  • le bug #1093, où même si un fork a été considéré comme incorrect, on réessaye malgré tout sans arrêt de switcher dessus. Bien qu’il soit important de revérifier sa compatibilité avec notre chaîne courante qui peut changer, retenter le switch alors que notre blockchain n’a pas changé est totalement inutile et contreproductif. Je pense que cela génère une instabilité.

Je corrige donc ces 2 bugs, et je pense qu’on sera alors tranquilles.

2 Likes

Et donc tu as refait une synchro complète et te trouves actuellement au bloc #41009 ?

http://gtest.duniter.inso.ovh/blockchain/current

Non, il tourne tout seul depuis ce matin…

La version 1.5.9 de Duniter est disponible : https://github.com/duniter/duniter/releases/tag/v1.5.9.

Encore une fois, une synchronisation est nécessaire. Vous pouvez de nouveau utiliser g1-test.duniter.org pour la synchro.

edit : ah ! un soupçon d’espoir ? “mayline” a installé un nœud qui calcule avec le mien ! c’est bon signe !

1 Like

Dans Duniter1.5.9 le current block est passé de 41015 à 44… et il est maintenant revenu au 41016.
Je laisse tourner mon nœud ou j’arrête Duniter?

Oui c’est juste un bug d’affichage. Son bloc courant est bien 41016, et ce qui est bon signe c’est de voir que sa valeur passe à 41017, puis 41018, …

L’autre valeur 44… ce sont les blocs de l’autre branche, qui nous polluent visuellement. Quand tu vois ce nombre s’afficher c’est donc que l’autre chaîne vient d’émettre un bloc.

C’est perturbant je sais, mais passons outre. Laisses ton nœud tourner stp ! :slight_smile:

ok merci!

Tu as bien refait une synchro avant de la lancer ? Si oui, peux-tu aller dans “Settings > Create a web link to your logs” et le partager ici ? Il n’y a pas d’info sensible dedans.

oui j’ai bien synchro mais cette fois j’ai conservé l’ancien dossier.config
http://hastebin.com/zonopetewe

Bon mon nœud est en train de se faire la blockchain en solo, en avance rapide.

Alors … je vous préviens dès qu’il a fini son truc et avec une difficulté acceptable, vous n’aurez qu’à rebrancher votre nœud dessus.

Merci pour les déblocages en tout cas :slight_smile:

Ça avance vite ici! :slight_smile: Ça c’est de la correction de bug à la chaine.

J’installe la version 1.5.9 ce soir. Si la blockchain avance à nouveau, je pourrai être certifié et avoir -enfin- un rôle utile. :slight_smile:

1 Like

J’ai réussi a te suivre mais je vais bientôt me faire éjecter de la toile :rofl:

Bon la chaîne est correctement repartie, mais il nous manque des nœuds !

Synchronisez sur g1-test.duniter.org, ça devrait passer tranquillement :slight_smile:

j’ai republié mon identitée: 5xDGRPWMojBjNC6tJ9rEW9wFuANktYtVYcwhGnJLZAVA

Certifié, cette fois ça a l’air d’être bien reparti! :slight_smile: Juste pour info j’ai inversé mes 2 nœuds (celui qui était sur gtest est parti sur g1 et vice-versa).

Duniter 1.5.9 installé et en cours de synchronisation. :slight_smile:

Rappel de ma clé publique : 8Sj3FBPx1AoTEvm49wN8YaUTzJv4NAv8zhVaXZ9eTBtN

Mise à jour vers 1.5.9 et synchronisation sur g1-test.duniter.org effectuées de mon côté.
A+