Duniter v1.7.17 : règle de distance non respectée

protocole
g1
g1-test

#1

Duniter 1.7 (<= 1.7.16) implémente de façon incorrecte la règle de distance. La version 1.7.17 corrige ce problème.

Télécharger Duniter 1.7.17 et resynchroniser son nœud :warning:

N.B. : cette version est susceptible de générer des softs-forks à court terme, tant que des nœuds membres en version <= 1.7.16 fonctionneront sur le réseau.

Il se peut donc que vous ayez à vous re-synchroniser plusieurs fois dans les semaines à venir.

Règle de distance non respectée

La version 1.7 de Duniter comportait un bug concernant l’expiration des certifications : lors d’une synchronisation le module de calcul de distance n’était pas informé de l’expiration des certifications et conservait donc des liens qui auraient dû disparaître.

Ceci a avantagé les renouvellements et entrées des membres sur les mois de Mars et Avril. Nous devrions pouvoir le vérifier, mais j’ai détecté au moins un cas de membre à distance de 6 lors de son entrée (Mel, entré au bloc#207153).

Le protocole devra tenir compte de cette/ces exceptions, nous devrons le mettre à jour une fois le correctif bien en place sur la Ğ1. Sinon, la blockchain paraîtra invalide au protocole.

Soft-forks à venir

Les nœuds vont réagir de cette façon :

  • les nœuds <= 1.7.16 (ou 1.7.17 non resynchronisés !) : accepteront tous les blocs du réseau
  • les nœuds >= 1.7.17 : n’accepteront pas les blocs où la règle de distance n’est pas scrupuleusement respectée

Il s’agit d’une situation de soft-fork, puisque le réseau tombera d’accord la plupart du temps, mais que les nœuds 1.7.17 introduisent une restriction supplémentaire.

Conséquence : tant que les nœuds <= 1.7.16 seront majoritaires, il y a des risques de fork non solubles pour les nœuds 1.7.17. En installant cette version, vous aurez un travail de suivi à réaliser ainsi que des resynchronisations si nécessaire. :warning:

Liens avec les forks des dernières semaines

Depuis 2 mois, un certain nombre de forks ont été causés par ce bug. De manière générale, les nœuds 1.6 forkaient relativement aux nœuds 1.7, donc notamment g1-monit, Remuniter, ğannonce, et d’autres miroirs.

Mais les nœuds 1.7 pouvaient aussi forker entre eux, selon le moment de leur dernière synchronisationn. Les forks se sont alors produits au gré des renouvellement / arrivées de nouveaux membres dont la distance était > 5.

Nouveautés

Dans mes investigations, j’ai rajouté la commande duniter dump wot afin d’afficher l’état de la toile dans le module de calcul de distance. Ainsi, j’ai pu détecter l’anomalie relativement à la version 1.6 de Duniter.

Versions Windows et ARM

@jytou, peux-tu t’en occuper stp ?

Voilà pour le rapport de bug.

:warning: N’oubliez pas de resynchroniser votre nœud pour appliquer le correctif ! :warning:


Certification invisible dans le bloc
Blocage de certains nœuds sur la Ğ1 depuis ce matin
#2

Resynchroniser, oui, mais sur quel nœud du coup ? :blush:


#3

Est-ce que la version pour ARM sera bientôt disponible ? J’aimerais tester sur la carte SD.

La synchro sur RPi avec la 1.7.16 plante net et sans erreur. J’ai essayé deux fois, la première ça s’est arrêté à un tiers, le deuxième un peu après la moitié. Il y a assez de place dans la partition et assez de mémoire. Est-ce que c’est un problème connu de cette version, si oui est-ce que c’est corrigé, si non est-ce qu’il vaut mieux que j’ouvre un post ou un ticket pour ça ?


#4

Je ne sais pas si j’ai bienfait mais synchro sur miroir principal en 15mn et tout de suite calculé un block.


#5

Je viens de lancer les releases ARM et Windows. À récupérer d’ici une heure si tout se passe bien.

@tuxmain j’ai aussi des problèmes aléatoires de synchro sur raspi, en général en relançant ça passe. Je me suis fait un script qui relance tant que la synchro n’a pas fonctionné :

#!/bin/sh
duniter stop
until duniter sync g1.cgeek.fr
do
	echo "Trying again..."
	sleep 5s
done
duniter start

C’est de la rustine mais ça marche bien. J’aurais peut-être dû ouvrir un ticket… mais je n’étais pas sûr que ça ne venait pas de ma carte SD par exemple. Du coup là on peut ouvrir un ticket, le seul problème étant que, comme toi, il n’y a aucune erreur donc il va être difficile de débugger…


#6

@tuxmain Fait pour l’ARM…


#7

Et fait pour Windows aussi.


#8

Perso, j’ai synchro sur g1.cgeek.fr

Je viens de mettre à jour et de synchroniser mes serveurs. Normalement vous pouvez synchroniser dessus :


#9

Un nœud qui n’est pas en fork :slight_smile: g1.duniter.org ou g1.cgeek.fr fonctionneront.


#10

Cc @Blacksmith


#11

Pourquoi faut-il attendre pour mettre a jours le protocole ? Si on ne tiens pas compte des exceptions immédiatement le bloc #207153 n’est d’ores et déjà plus valide non ? il y a quelque chose qui m’échappe la :thinking:


#12

Mon nœud est à jour.


#13

Tant que la 1.7.17 est minoritaire (ou que les nœuds 1.7.17 sont présents mais pas resynchronisés), d’autres exceptions de distance peuvent se produire. Donc autant attendre que la situation soit stabilisée.


#14

Et resynchronisé ? C’est important :slight_smile:


#15

On est d’accord que pour resynchroniser, le mieux c’est d’effacer tous les fichiers (sauf conf et keyring) et relancer de rien ?
La méthode “propre” n’est pas encore fiable sous Duniter-desktop ?


#16

Oui, malheureusement pour ceux utilisant l’interface graphique (donc la version Bureau), mieux vaut éteindre le nœud et supprimer les fichiers soi-même.


#17

Salut,

Donc pour ceux qui utilisent la version de bureau, on doit supprimer quoi exactement ?

$ ls -al ~/.config/duniter/
.rw------- 8,4M simon 16 avr 14:15 BrowserMetrics-spare.pma
drwx------    - simon  2 avr  6:53 Crash Reports
drwx------    - simon 17 avr 17:32 Default
drwxr-xr-x    - simon 17 avr 17:32 duniter_default
.rw-rw-r--    0 simon  1 avr 13:11 First Run
.rw------- 5,0k simon 17 avr 17:32 Local State
drwx------    - simon  1 avr 13:11 NativeMessagingHosts
drwx------    - simon  1 avr 13:11 ShaderCache

Le gros des données est dans le dossier “duniter_default” :

--- /home/simon/.config/duniter --------------------------------------------------------------------------
  656,5 MiB [##########] /duniter_default                                                                 
    8,0 MiB [          ]  BrowserMetrics-spare.pma
  696,0 KiB [          ] /Default
  624,0 KiB [          ] /Crash Reports
  196,0 KiB [          ] /ShaderCache
    8,0 KiB [          ]  Local State
e   4,0 KiB [          ] /NativeMessagingHosts
    0,0   B [          ]  First Run

Mais il faut garder “duniter_default/conf.json” et “duniter_default/keyring.yml” ?


#18

Tu peux supprimer tout ce qui est dans $HOME/.config/duniter/duniter_default sauf keyring.yml et conf.json pour conserver ta clée et ta configuration.

Sinon, depuis l’interface graphique c’est également possible :
Settings > Data > Reset Data and start sync.


#19

Merci @Moul.

J’ai coupé le logiciel et supprimé tous les fichiers saufs keyring.yml et conf.json.

Je faisais via l’interface graphique avec un “reset data and start sync” mais vu que @cgeek dit qu’il vaut mieux le faire “à la main”…


#20

duniter.jokeur.fr mis à jour et resynchronisé