Je reformule : le compte de la Trésorerie ne doit pas être vide à la création du Genesis et sa valeur doit être supérieure à l’ExistentialDeposit (1,00 Ğ1). Pour ne pas créer cette monnaie, il faut donc la transférer depuis un compte existant de la Ğ1 actuelle.
Ce transfert peut être effectué automatiquement lors de la génération du Genesis, il faut juste avoir la clé publique du compte concerné et que celui-ci dispose d’au moins 1,00 Ğ1.
Je propose d’ajouter un paramètre pour la configuration de chaque monnaie (gdev.json, gtest.json puis g1.json) qui indique le compte Ğ1v1 qui fondera cette Trésorerie. Par défaut je vais indiquer mon propre compte.
Mais peut-être qu’on pourrait au contraire créer un compte de Trésorerie dès maintenant dans la Ğ1 que personne ne maîtrise et permettre à chacun de contribuer ? Si vous réagissez peut-être qu’on peut faire ça, sinon je reste sur mon idée de départ.
Ça peut être les comptes qui ne sont pas accessible en Ğ1v1 car hors de la courbe 25519. Je l’avais fait côté py-g1-migrator par nécessité car ces comptes ne peuvent pas être déplacés créés en v2 car Duniter v2 vérifie que les comptes sont bien sur la courbe. On peut aussi simplement ignorer cette monnaie côté migrator, et juste se baser sur la différence entre monnaie théorique (masse monétaire) et monnaie observée (somme des comptes) pour alimenter la trésorerie et rétablir l’égalité entre théorie et pratique.
(mais si tu veux faire autrement et alimenter la trésorerie de 1Ğ1 à partir de ton compte ou d’un autre ça me va aussi, pas de problème)
Oui les comptes “hors courbe” sont de bons candidats aussi.
Ce point n’est pas tranché, personnellement j’ai du mal à expliquer que l’on va revenir sur les actions des utilisateurs ou sur les règles passées du protocole.
Mais si une explication convaincante était donnée, oui, ces unités pourraient participer également.