Un ami ouvre un compte portefeuille
Il me copie/colle la clé public que lui donne Césium (sans checksum) et je lui fait un virement de bienvenu.
Après la première authentification qui suit la création du compte, il me recopie/colle à nouveau sa clé avec son checksum…
Elle est différente à 1 caractère près !
En fait, lorsqu’il m’a transmi sa clé la première fois, il a utilisé un logiciel OCR qui à transformé un “b” et “d”
J’ai donc fait un virement sur un compte n’appartenant (confirmez-moi) à personne :
Gpe9DdeUDyrAsKTBoQFpQiGwMefxVeXu4xVEHmXDEwiY
Les donneurs de leçons me diront que c’est bien fait pour moi, que j’aurais dû être plus prudent, moins pressé.
Merci pour leur empathie débordante…
Au delà de ça, je pense que les utilisateurs de Césium devraient être informé du risque de virement vers des comptes fantômes
ou plus raisonnablement qu’il soit implémenter un garde-fou pour empêcher les virements vers des comptes non lié à une identité.
Je pourrais même rêver à ce que le garde-fou soit rétro-actif : que les junes envoyé vers des comptes sans identité
soit renvoyés d’où elle viennent
En espérant faire avancer Césium et la monnaie libre,
Le problème est que Cesium ne peut pas savoir si on voulait effectivement envoyer de la monnaie à un compte vide ou non.
Ce qu’il pourrait faire, c’est mettre un avertissement si la clé est donnée sans checksum et que le compte est inactif (zéro document blockchain ou Cesium+ émis).
En bonus, il pourrait chercher les clés très proches (différant de quelques caractères au maximum) et les suggérer.
Les comptes sans identité doivent aussi pouvoir recevoir des paiements en toute confiance (sans crainte d’annulation), donc non. C’est aux clients d’implémenter ce garde-fou.
Dans Duniter v2 les checksums seront toujours intégrées dans les adresses de comptes donc ce problème deviendra très rare, même sans garde-fou plus sophistiqué.
Merci de tes explications. En fait, je ne comprends pas bien l’architecture…
Le compte sur lequel j’ai fait le virement est-il relié à une identité ? Une identité, cela veut-il dire qu’il existe un identifiant et un passe pour s’y connecter ? Où sont stocké id et pass et compte lié ?
J’imagine que pour DUNITER, un compte est juste une clé public, n’est-ce pas ? Dans ce cas, effectivement c’est au client (Césium en l’occurence) de mettre en place les garde-fous
Non. Il n’y a pas d’indentité liée à cette clé publique.
C’est de la cryptographie clée publique/clé privée. Toutes les clées existent, mais les identifiants pour les contrôler sont plutôt très dur à trouver avec beaucoup de puissance de calcul, voire impossible. Donc, malheureusement les 100 DU que tu as envoyés peuvent être considérés perdus.
Merci. Comme on peut savoir si une identité est liée à une clé public, pourrait-on envisager de coder un garde-fou dans Césium pour éviter les virements vers des comptes fantômes ?
Y a t-il un intérêt pour un utilisateur d’un client comme Césium de faire de tels virements et même de voir les comptes fantômes non liés à une identité ?
En fait, s’il existe une couche logiciel d’interface entre le protocole DUNITER et les applications clientes destinées aux utilisateurs de la June, un tel garde-fou pourrait en faire partie. Non ?
silkaj wot lookup Gpe9DdeUDyrAsKTBoQFpQiGwMefxVeXu4xVEHmXDEwiY
No identity found for Gpe9DdeUDyrAsKTBoQFpQiGwMefxVeXu4xVEHmXDEwiY
Avec Cesium ça doit surement être possible.
Oui, il est possible d’implémenter ce garde-fou.
Les portemonnaies non liés à une identité permettent aux êtres humains pas membre de recevoir des Ğ1 et à tout le monde de gérer plusieurs portemonnaies.
Cesium fait déjà cette vérification, pour un compte sans identité il n’affiche qu’une clé publique et pas de pseudonyme. Ce qui pourrait être ajouté est la détection de l’inutilisation du compte, et un avertissement associé.
Je ne sais pas si BMA ou GVA permettent de détecter si on compte n’a jamais été utilisé, en tout cas dans Duniter V2 non. Mais les indexeurs (pour l’instant Cesium+) peuvent le faire facilement.
C’est bien les compte inutilisés qui posent problème, dans plein de situations légitimes on veut transférer à un compte sans identité, par exemple pour donner à la cagnotte des développeurs ou pour utiliser un compte portefeuille autre que son compte membre (pour des raisons de sécurité).
Excusez la confusion de vocabulaire que je faisais en écrivant “Compte sans identité”, je voulais donc dire “compte inutilisé”, c’est à dire qui ne correspond ni à un compte membre ni à un compte simple portefeuille. Faudrait renommer le thread.
Et donc le compte sur lequel j’ai malencontreusement fait un virement
Gpe9DdeUDyrAsKTBoQFpQiGwMefxVeXu4xVEHmXDEwiY
est-il inutilisé ? Dans Césium, j’ai essayé d’écrire un message à son propriétaire et j’ai eu un message d’erreur mystérieux :
nacl_raw._crypto_sign_ed25519_pk_to_curve25519 signalled an error
La clé publique d’un compte est calculée de manière déterministe à partir du couple de mots de passe. On peut considérer que la distribution des clés publiques est aléatoire : si un caractère du mot de passe change, la clé change radicalement. Il est aussi impossible de retrouver les mots de passe à partir de la clé.
Ainsi on voit qu’une clé trouvée au hasard, ou une clé valide ayant subi une erreur, n’ont qu’une infime (pratiquement nulle) chance de pouvoir être calculées à partir d’un couple de mots de passe possible, donc une chance encore plus faible qu’un tel mot de passe soit utilisé par quelqu’un.
De plus l’erreur signifie que la clé n’est pas valide pour la cryptographie. En effet, une clé mal formée peut ne pas avoir les propriétés mathématiques nécessaires pour chiffrer un message. Donc même si quelqu’un l’utilisait, il lui serait impossible de dépenser les G1 reçues.
Je ne serais pas contre un remboursement des transactions envoyées à des clés invalides. Cela ne pourra se faire que lors de la migration v2. Il me semble que la décision retenue est pour l’instant de vider ces comptes dans une cagnotte commune, mais rembourser les transactions est techniquement possible.
Houa ! passionnant de vous lire, j’en apprends tant. Si j’avais 20 ans de moins, je viendrais vous aider au développement.
Si je comprends bien, en cas d’erreur dans la clé (et quand elle n’inclue pas le checksum !), il y a donc de très grandes chances que ce soit une clé invalide par rapport à la fonction de cryptage. Si le test de la validité d’une clé est facile à faire, il serait donc simple d’implémenter un garde-fou qui serai efficace dans la grande majorité des cas (cas des clé invalides). Un garde-fou qui fonctionnerais pour toutes les clés inutilisé est peut-être plus coûteux et délicat à coder…
En souhaitant faire avancer la June, Et c’est vrai, si un jour je récupérais mon malencontreux virement, ça me ferais plaisirs
