Bonjour,
Je viens mettre un peu le bordel 
De mon observation, les utilisateurices se basent souvent sur le début de la clef pub (5-6 caractères)pour valider que le compte est le bon, et regardent rarement la fin.
Compte tenu de cette observation, serait-il adapté de placer la checksum avant la clef pub, de manière à ce que les utilisateurices voient en même temps la checksum et le début de la clef ?
format :
<checksum>:<clefPub>
Ae3:Bgx8…
C’est une bonne idée !
Mais est-ce que ça ne va pas porter à confusion l’utilisateur peu avertis ?
Croyant que le checksum est la clé publique en rétrécie.
L’information importante est d’habitude mise en premier.
Oui, c’est vrai que du coup iels vont peut-être se mettre à contrôler uniquement la checksum… Ce qui est le contraire de l’effet attendu.
Donc pas si bonne idée que ça. Disons que ça demanderait des tests d’ergonomie que nous n’avons pas les moyens de faire . Je retire ma proposition.
A moins qu’on retire les :, du coup l’ensemble deviendrait comme une clef pub rallongée et seuls les clients sauront que :
Ae3Bgx8…
Mais globalement oui, l’info principale est la clef pub, c’est mieux de la garder en 1er.
Excellente idée, ce caractère séparateur est inutile, il vaut mieux le retirer 
Cela ne me paraît pas un bonne idée. Il y a plein de manière de calculer un checksum. Celle utilisée par Cesium pour parser les QR code est celle de la spécifications des wallet paper réalisée par Tortue. Cependant, elle est un peut compliqué à réaliser, et même à vérifier. Cela pourrait être plus simple dans un autre version qui deviendrait alors la norme.
Mieux vaut séparer clairement ce contrôle (qui pourrait changer) de la clef (qui ne changera pas).
Sakia offre un checksum aussi, mais je n’ai pas regardé comment il est fait.
Il faut impérativement séparer le checksum avec un « : » ce évitera de mélanger des pubkey avec ou sans et de devenir fou à ne pas comprendre pourquoi la pubkey est invalide (ben t’as pas vu, y a trois caractères en plus… 
).
Sinon, pour sécurisé un virement, Sakia permet d’envoyer un virement récupérable simplement après une semaine en cas de problème.
Bonjour à tous,
Premier message sur le forum, et utilisateur de la June depuis peu, je tiens d’abord à remercier toutes les personnes qui participent au développement des outils de la June, bravo !
Je profite du sujet car il m’est arrivé une histoire semblable et je voudrais savoir si il y a une solution pour « corriger le tir ».
J’ai donné ma clé publique à une amie afin qu’elle me paie, mais elle n’a pas fait de copier/coller, elle a commencé à rentrer manuellement les premiers caractères (5 ou 6), et Cesium lui a proposé une clé, sur laquelle elle a cliqué (le 15/07). Hors ce n’était pas la mienne.
Et ce compte liée à cette clé publique ne contient, encore aujourd’hui (le 30/07), que les junes versées par mon amie. C’est comme si, le fait d’avoir cliquer sur la clé proposée par Cesium lorsqu’elle à commencée à saisir la mienne manuellement, avait généré un nouveau compte portefeuille.
Voici les clés publiques des 2 comptes
Clé publique du compte crédité par erreur : Ab1MsqBxaT1cNU4id5Jp4yvwR8wF4SVpqhM34QEPLTsm
Clé publique de mon compte Matwall1 : Ab1MsqBxaT1oNU4id5Jp4yvwR8wF4SVpqhM34QEPLTsM
Je voudrais savoir si il est possible de vérifier si ce compte appartient bien à quelqu’un ou si c’est un compte « fantôme » comme j’en ai l’intuition ?
Auquel cas, y a t-il une solution pour re transférer ces junes sur le compte de mon amie ?
Merci beaucoup
Mathieu
Bonjour,
Si la clé erronée diffère d’un unique caractère d’une clé dont vous avez les identifiants, c’est très, très probablement un compte inaccessible à jamais, peut-être même dont les identifiants n’existent pas.
Il existe 256^32 = 115792089237316195423570985008687907853269984665640564039457584007913129639936 clés publiques, la probabilité d’en trouver une utilisée par hasard est pratiquement nulle.
bon compte : Ab1MsqBxaT1oNU4id5Jp4yvwR8wF4SVpqhM34QEPLTsM
mauvais : Ab1MsqBxaT1cNU4id5Jp4yvwR8wF4SVpqhM34QEPLTsm
Impossible à vérifier. Mais c’est très probablement un compte au hasard. Il existe (il a de la monnaie), mais personne n’en connaît les accès.
Non (enfin si, mais ça reviendrait à effacer toutes les transactions sur tous les comptes G1 depuis le 15/07, et ça demanderait des manips de la part de tous les noeuds, donc non, on ne va pas le faire).
Pouvez-vous nous dire précisément sur quel champs c’était ? (recherche dans l’annuaire, recherche lors de l’envoi d’une transaction, autre ?) Pouvez-vous confirmer, assurer, sûr 100% que la clef publique n’a pas été recopiée en entier, mais que qeuls les premiers caractères ont été entrés et que c’est Cesium qui a proposé cette mauvaise clef publique ? (demandez à votre amie)
Il est prudent de vérifier la propriété du compte avant, en envoyant 1G1 dessus et en demandant au propriétaire de la renvoyer.
Troisième cas d’erreur de destinataire de ce type en deux semaines. Et vraisemblablement, pour deux cas, ce ne sont pas des fautes de frappe, mais une proposition de Cesium après avoir entré 6-8 premiers caractères !? ça me paraît très, très étrange, comme comportement.
Suite à ces deux cas (l’autre est ici), je pense comme @Vit que les clients devraient :
Pour ce qui concerne l’affichage, il arrive pour des questions de place de ne vouloir afficher que les premiers caractères de la clef publique. Dans ce cas, il me semble tout aussi essentiel d’afficher le checksum, pour éviter les mêmes mésaventures. Je propose donc deux formats d’affichage :
Ping @Moul @kimamila qui sont directement concernés.
pour référence, le format de checksum utilisé est décrit là (en bas de la page) : https://tmp.tednet.fr/paperwallet/AddressFormat.html
Oups, je n’avais pas vu qu’il y avait deux passes de SHA256. Quelle est la motivation d’en mettre deux plutôt qu’une ? (apparemment c’est comme ça en bitcoin aussi)
Je vais corriger natools. Edit: fait.
Oui, c’est une des raisons qui me freine de l’implementer partout au niveau de l’affichage, dans Cesium : les deux passes de sha256 ne risque elle pas de ralentir certaines fonctionnalités ? Par exemple l’annuaire. Faudra que nous testions cela…
Bonjour,
Je vous confirme que la clé publique n’a pas été recopier entièrement, Cesium lui a proposé une clé publique en cours de saisie, avec le début idem mais dont la suite ne correspondait pas à la mienne.
Mon amie dit que c’est pendant la phase du virement. Elle a commencé à rentrer la clé du destinataire manuellement, et arrivé à une dizaine de chiffres, Césium (apli mobile) lui a proposé une clé.
Elle n’a pas contrôlé pensant que c’était ma clé, et a cliqué dessus.
pourquoi avoir utiliser dans certains cas pubkey!sum et dans d’autres pubkey:sum ?
Sachant que le ! n’est, si je ne me trompe, pas safe coté url alors que le : oui.
C’est un choix qui a été fait à l’époque par le projet Silkaj pour pouvoir séparer les clés publiques pour l’envoi de transactions multi-destinataires. C’est le seul projet client Duniter à avoir fait ce choix.
Silkaj < v0.6.0 :
tx --output <pubkey>:<checksum>
Silkaj v0.6.0 qui implémente les tx multi-destinataires − v0.7.6 :
tx --output <pubkey1>!<checksum1>:<pubkey2>!<checksum2>
Silkaj v0.8.0-dev qui utilise à présent une fonctionnalité de Click. Retour à la case départ avec : comme séparateur :
tx --recipient <pubkey1>:<checksum1> --recipient <pubkey2>:<checksum2>