Je suis pour changer ce qui est fait actuellement dans Ğecko pour:
Générer le wallet root par défaut : expliquez moi en quoi ce serait une vulnérabilité si on génère plusieurs dérivation. C’était l’argument d’elois.
simplement incrémenter ensuite //0, //1, ect…
On réserverra une plage pour les autres type de dérivation opaques plus tard.
c’est pas grave si les différents outils font différemment tant qu’on scan tous une plage de dérivation commune (de 0 à 30 par exemple)
Même si un client ne gère pas les dérivations par défaut il est obligé de scanner à l’import @HugoTrentesaux. Ça évite de devoir indiquer les numéro de dérivation aux users.
Perso j’ai pas trop les compétences pour analyser ça, mais j’ai l’impression que tant qu’on ne partage pas les clés privées de dérivations transparentes, il n’y a pas de risque de remonter à la clé privée du chemin racine.
Ça me semble sain.
Effectivement, ça viendra quand on développera des cas d’usage grand public. Et on peut toujours utiliser des chemins du genre mnemonic/rfc-xx/che/min/com/pli/qué.
Dans le cas de Duniter Portal, c’est qui le client qui est “obligé de scanner à l’import” vu que la gestion des clés est délégué à Duniter Connect ? Pour l’instant je prévois pas du tout de gérer de HD wallet, mais de complètement déléguer à Duniter Connect la gestion des clés. Mais peut-être que c’est possible pour une app de demander à Duniter Connect d’importer les dérivations, (= les afficher à l’utilisateur et exposer les adresses dans la liste des comptes).
Duniter connect et portal n’est pas destiné au grand public mais aux dev et users avancés donc on peut tolérer d’importer les dérivations par path directement.
Pas tout à fait, c’est un outil pratique pour les forgerons, et avec l’exemple de @BulmAnanaBelle on a vu que c’était pas facile de devenir forgeron en utilisant son compte membre Gecko parce qu’il fallait ruser pour trouver la dérivation sur laquelle elle s’était fait certifier.