À 90% codé par Claude 3.7 Sonnet
avec quelques compléments de DeepSeek et Cascade Base via Windsurf.
Démo en ligne :
https://crypto-checker-39275d.pages.duniter.org/
3 Likes
A quoi ça sert de distinguer ces 2 types de clefs ?
Avec les choix qui était fait jusqu’ici, à distinguer les clef historique dérivée en ed25519 façon cesium v1, donc avec une sécurité incertaine (puisque les utilisateurs peuvent avoir mis des mots de passe triviaux)
et les clefs en sr25519 générée depuis un mnémonic par gecko ou gcli ou duniter connect. Donc avec une meilleur sécurité.
Ce qui m’a donné envie de coder cet outil c’est de pouvoir vérier que les forgerons V2 sont bien avec des clefs sr25519 (donc qu’ils ont de bonne pratique de sécurité).
Pour autant, au regard de ce topic :
il est probable que les adresses généré depuis mnémonic soient en ed25519 aussi et donc que mon outil ne serve plus à grand-chose dans notre contexte.
(si ce n’est l’intérêt pédagogique pour moi d’essayer de développer un programme en pilotant la rédaction de code par des IA)
3 Likes
C’est exactement ce que j’ai conclu aussi. 
J’ai trouvé une autre solution pour distinguer si un compte est v1 ou v2, grâce à l’indexer.
Les comptes v1 ont une date createdOn à 0, les autres une valeur > 0.
Pour lister uniquement les comptes V2 par exemple :
query {
account (where: {
createdOn: {_gt: 0 }
}) {
id
createdOn
identity {
name
}
}
}
3 Likes
Si on transfère un compte V1 en V2 (l’identité et les certif resent les même mais on change d’adresse pour une adresse générée depuis mnémonic) est-ce que ça compte comme createdOn 0 ou > 0 avec ton système @vit ?
Comme tu le dis, seule l’identité et la monnaie sont transférée, ce qui ne change pas la date de création des comptes. Le compte V2 reste forcément avec createdOn > 0. Le compte V1 reste avec createdOn == 0.
On peut avec duniter connect crée un compte avec id/mdp dans la gdev
Je ne sais pas si ce sera possible avec césium².
Il y aurait alors une date de création ?
Voir compte 5Dsr4W2ymDkpSPnTDY1XtCnHD2BY559fpFux9ZEGfGzq5jPs
Que j’avais créé avec duniter connect pour une démo.
2 Likes
Je crois qu’il y a méprise theminologique entre:
- compte id/password scrypt
- compte Ğ1 créé avant la migration
1 Like
Bien vu. Mais la blockchain qui reçoit une clef publique n’a aucun moyen de savoir comment a été généré la seed, à partir de laquelle est généré le trousseau de clefs. On pourra toujours avoir des comptes dont on ne saura pas s’il sont générés façon V1.
On peut même, si je ne me trompe, générer une seed V1 id+pass, puis la convertir en trousseau SR25519 !
Ma conclusion est qu’il n’existe aucune moyen fiable de savoir si un compte a été généré par un mnémonique ou non. Sauf pour les comptes avec CreatedOn == 0.
La bonne pratique pour un client V2 serait alors de ne proposer de contrôler un compte par id+pass uniquement pour les comptes connus et créés au bloc 0 (createdOn == 0).
Comme c’est une idée de @poka, je propose que ce soit lui qui résolve tous les problèmes que cela soulève ! Mouaahahahahahah ! 
2 Likes
Non aucun moyen fiable de savoir est créé avec mnémotechnique ou non, mais est-ce un problème ?
Les clients pourraient aussi simplement refuser l’accès par id/mdp, si le compte est à zéro.
Avec un message “ce compte n’existe pas ou plus”.
Dans Tikka oui. Quand Tikka a une adresse de compte, mais pas la clef secrète, on peut restaurer la clef secrète. Tikka ouvre un formulaire pour entrer un mnemonique ou entrer id+pass selon le type de compte V1 ou V2 (actuellement ED25519-> id+pass, SR25519-> mnemonique).
J’ai donc besoin de savoir distinguer ces deux types de comptes.
Mais c’est bon, je vais refuser le suivi/contrôle des comptes V1 non existants ou existant mais avec CreatedOn > 0. Ainsi, seul un compte V1 existant et venant du genesis pourra être géré en id+pass.
3 Likes
Tu peux aussi demander à l’utilisateur de choisir sa méthode d’authentification, comme le fait césium.
En cas d’authentification par id/mdp refuser d’aller plus lois si le compte est vide.
Cela doit être faisable, il me semble !
C’est déjà le cas, l’utilisateur peut ajouter (dans les comptes de Tikka) un compte V1 avec id+pass dans Tikka.
Mais vérifier que le compte soit “vide” (solde == 0) ou inconnu (solde == Null) n’est pas une méthode fiable.
Imagine que quelqu’un crée un compte en V2 avec id+pass (via gcli, duniter-connect, ou même Tikka ou avec un programme de son cru). Il alimente le compte. Le compte n’est pas vide mais je veux pourtant interdire son accès dans Tikka s’il n’est pas dans le génésis !
Je ne peux donc compter que sur la date de création du compte, le solde n’étant pas un indicateur de compte V1.
1 Like