Un bug critique a été détecté aujourd’hui : des membres devant être exclu ne le sont pas.
Conséquences : annulation de la journée du 23/02/2017
Je vais déployer une version corrective dans l’heure (0.90.7), puis vais repartir d’un bloc valide de la blockchain : il s’agit du #8466. Je vous demanderai alors de vous mettre à jour, de remettre votre nœud à zéro et resynchroniser sur un des 2 nœuds proposés (gtest.duniter.org:8999 ou api.gtest.duniter.org:80).
Ceci afin de conserver une blockchain cohérente où les règles initiales sont respectées.
TOUTES LES DONNEES DU 23/02 SERONT ANNULEES : transactions, certifications, etc.
Par avance merci d’effectuer cette opération (reset + resynchro en 0.90.7) pour le bon déroulement de ĞTest.
Détails
C’est @Tortue qui a constaté que l’exclusion des membres par manque de certifications n’était pas opérante. En effet, il a patiemment attendu que le cas se produise pour lui : hier, il est tombé à 1 certification (pour 3 requises) mais est resté membre, produisait des DU, et pouvait calculer des blocs.
En effet, Duniter n’a pas acté son exclusion.
Il s’agit d’un bug critique sur lequel nous ne serions tombés que dans 2 ans. Fort heureusement, une personne veillait au grain.
pas plus mal peut etre car ça va peut etre purgé mes info erronée ou en doublon , je me melange encore le pinceau entre les noeux et les clients duniter
C’est intéressant nous expérimentons un vrai fork entre 2 visions de la monnaie qui poursuivent toutes deux leur existence, même si chaque blockchain avance plus lentement.
Pour l’instant nous sommes peu nombreux mais comment fera t-on pour déployer un correctif lorsque nous seront une centaine de nœuds membres ? Comment s’assurer que les nœuds qui tardent a ce mettre à jours m’empêchent pas la monnaie d’avancer ?
@cgeek, est il possible de faire en sorte que la difficulté de chaque fork soit indépendante de manière a ce que les nœuds qui tardent à ce mettre à jours m’empêchent pas la monnaie d’avancer ? Je parle uniquement des fork causés par un changement de version, pas des fork réseau.
En fait, la difficulté va s’adapter : tous les 10 blocs dans ĞTest, celle-ci diminue ou augmente en fonction de la variation de temps sur les 20 derniers blocs.
Il faut aussi voir que, pour éviter le fork sur une mise à jour, il est possible de prévoir son déclenchement a posteriori. On l’a déjà fait sur TestNet, c’était propre. Par contre ce n’est pas adapté au hardfork tel qu’on le fait ici, mais là on parle d’un bug critique, digne de ce qui s’est passé dans Bitcoin quand un utilisateur a produit une transaction à montant négatif.
On a essayé de répondre à cette problématique en changeant le protocole de rotation de difficulté. Cette dernière c’est trouvé rendre la difficulté trop élevée et Duniter est repassé à sa version original.
Oui mais dans la pratique cela peut empêcher la monnaie de fonctionner quelques jours. La par exemple comme l’a fait remarquer @moul sur le salon, la monnaie est bloquée car les nœuds membres à jours ont tous calculé un bloc il y a peu !
Il y a aussi un problème de paramétrage de Ğ1 : la difficulté exclu 50% des calculateurs plutôt que 33%, ce qui est particulièrement handicapant et empêche d’émettre plus de bocs.
Au pire la monnaie est bloquée. Mais après tout, on n’a pas plus raison que la branche historique.
Nous sommes toujours bloqués ce matin, pourtant nous avons suffisamment de nœuds sur le fork pour avancer.
@jytou, @jeanferreira, @mamygeek, @elois, @urodelus, pourriez-vous me faire un backup de votre nœud (Settings > Backup > Create a backup), l’héberger sur Framadrop puis m’envoyer le lien par MP ?
Urodelus devrait avoir calculé le 8473 depuis longtemps, ce n’est pas le cas. Pour les autres, votre nœud est bloqué sur le 8471 alors que le suivant est déjà calculé et disponible sur le réseau.
J’aimerais comprendre ce qu’il se passe, et vous dire ce qu’il convient de faire pour débloquer la situation.