Aucune des 6 ne passe en l’état.
Quoi que je change, les 3 premières ne passent pas.
La 4ème avec que des 1, si j’en enlève suffisamment pour qu’elle fasse 32 bit, elle passe coté point ed25519, mais pas pour les règles de longueur en b58 définie par Duniter.
Les 5 et 6ème ne passent pas en l’état, mais si je supprime le premier ou le dernier caractère, elles deviennent valides.
Du coup, pour les 2 dernières, je me demande comment elles ont été générées, mais il est possible qu’une clef privée soit associé aux versions avec 1 caractère de moins et qu’un bug de conversion et rajouté un caractère…
Si c’est le cas et que le bug est présent en sens inverse, il est peut-être possible de produire une transaction qui utilise ces fonds, mais ça me semble quand même hautement improbable.
Ce que je propose : expliciter lors de la migration que ces 6 clefs sont invalides dans la nouvelle version, qu’elles sont issue d’un bug, mais que si quelqu’un est capable de reproduire le bug en montrant qu’il dispose de la clef privée qui génère cette clef publique, on est ok à lui verser le montant qui était sur le compte avant migration s’il se manifeste moins d’1 an après la migration. (et si ça à lieu, tant qu’on est sous les 500Ǧ1, je veux bien verser le montant à partir de mes fonds propre)
Désolé je suis plus très dispo.
C’est normal pour les membres forgerons, car la pallet session « consomme » le compte pour stocker les sessions keys.
Par contre, ça ne devrait pas être le cas pour les comptes non-forgerons.
En effet c’était en testant sur mon compte membre poka que j’observais ce consumer, hors il était dans le groupe smith… En le retirer de smith, le consumer est bien absent, et donc la migration identité + solde se passe sans soucis sur gecko.
Donc pour résumer, je n’observe plus de bugs concernant le storage ĞTest pour le moment.
Voici donc les points à aborder avant le lancement d’un live ĞTest:
Détailler dans un ticket les changements à faire côté runtime entre ĞDev et ĞTest.
Ne pas oublier le cas des certifications émises par des comptes non membre
Éventuellement prévoir un bloc revoked username dans le genesis, et sa prise en charge côté Duniter
Implémenter ces changements
Créer des scripts python ou rust pour faciliter le lancement d’un live network, pour le paramétrage genesis avec les identités de dev, ajout au groupe smith avec certifications, comité tech. Ainsi que la génération et gestion des sessions keys. Pour le reste, ce qui concerne la visualisation des votes pour runtime upgrade, votation, tout ceci nécessitera un outil web dédié.
Ce sera une ĞDev avec des données réelles issues de la Ğ1 qui permettront de concevoir les UI plus facilement (existence de données Cesium+ rattachées, nombre de certifications émises et reçues réalistes…). Son lancement se fera lors du hackathon de novembre, d’ici là il faut que je teste et finisse de documenter le processus (d’autres choses moins importantes mais plus urgentes avancent entre temps).
J’essaie de comprendre un peu comment ça marche. Et il me manque une étape : comment sont extraites les données de duniter v1 ? J’ai tenté un dex export-bc mais ça ne produit pas ce qui est réclamé par le script python : il râle sur un fichier ud_value.json qu’il ne trouve pas.
Il semble que py-g1-migrator n’ait pas produit de fichier blocs.json depuis le 9 mai alors qu’il continue bien à produire les autres fichiers. @poka est-ce que tu as une idée de pourquoi ?
En effet, c’est la commande./dex find main_blocks qui crash au bout d’une vingtaine de secondes:
$ time yes|./dex find main_blocks -p medianTime -o json
Database opened in 0.085576 seconds.
Killed
real 0m12.755s
user 0m18.913s
sys 0m15.138s
Là où les autres commandes dex fonctionnent correctement.
Malheureusement dex ne me donne aucune info sur la cause de ce crash.
Je suis sur Duniter v1.8.6 sur cette machine.
J’ai recompilé duniter depuis la branche dev sur mon pc, ainsi que dex, ça synchronise actuellement, je verrai si j’ai le même soucis ici.
Si oui il faudra soit debuguer dex, soit exporter les données de ces blocs autrement.
edit:
Bon va savoir pourquoi, en passant l’option -l 1000000 pour définir le nombre de ligne à exporter par dex, et bien la commande fonctionne correctement en exportant toutes les lignes…
A la base je souhaitais simplement isoler la ou les lignes posant problème, pour finalement me rendre compte qu’en voulant debuger, ça règle le problème…
J’ai donc mis à jours le script en conséquence pour contourner le soucis, qui semble donc venir de dex et non d’une db corrompu (ce que je redoutais). Les données sont donc à jours.
Ah oui, en effet, j’avais regardé sur Cesium par habitude et je devais être sur un nœud désynchronisé . Merci ! Entre temps j’ai ajouté le champ next_cert_issuable_on mais il me reste à trouver comment obtenir la date d’expiration de l’adhésion avec dex.
récupérer l’adresse de la trésorerie pour déplacer la monnaie ignorée
utiliser le bon préfixe ss58 pour les addresses
comprendre pourquoi la masse monétaire n’est pas strictement égale à la somme des comptes et corriger (cf Quantité de monnaie sur Duniter)
valider que les conversions timestamp → nombre de blocs se font côté py-g1-migrator (implique un léger décalage de timing sur les expirations de certification par exemple, cf utilisations de date_to_bloc_number)
. Merci ! Entre temps j’ai ajouté le champ