Du coup, ça devient un bug de cesium, lequel renvoie sur le compte de Florence : 4ppWsXtJ9Vyq6dLntQMb3FZzbvcK69mz64w8NJkjN1Rm
alors qu’on veut aller sur le compte : 4ppWsXtJ9Vyq6dLntQMb3FZzbvcK69mz64w8NJKjN1Rm (essayez avec la recherche de clef publique, ou dans l’historique de tx de Filoulibre.)
Bug confirmé sur GTest :
Claude (en attente de certif) - 6upqFiJ66WV6N3bPc8x8y7rXT3syqKRmwnVyunCtEj7o
Si je cherche la clef pub 6upqFiJ66WV6N3bPc8x8y7rXT3syqKRmwnVyuNCtEj7o, Cesium me propose le compte de Claude.
C’est le deuxième cas de faute de frappe que j’observe en deux jours. Je vais me mettre à utiliser des checksum
Si l’entrée est une clé publique valide entière, alors la recherche devrait être sensible à la casse, et le compte correspondant exactement à la recherche devrait sortir en premier, avec un message du type « comptes avec une clé publique similaire », suivi des comptes existants avec une clé publique ressemblante. Si la recherche est un morceau de clé publique valide, le même comportement devrait arriver (clés publiques contenant exactement le morceau, puis message, puis clés publiques contenant un morceau similaire).
Un autre problème est que les non-membres en attente de certif n’ont pas la mention rouge « non membre » dans l’annuaire.
Duniter/BMA wot/lookup est insensible à la casse. Aux clients BMA de faire attention à vérifier que c’est la bonne clé publique (égalité avec casse incluse).
Requête avec un K clé sans identité attachée et j’obtiens la clé avec un k où l’identité est rattachée :
ce que j’ai compris… c’est un sujet de qlq qui n’a pas coupé/collé le cle public (ou peut etre oui et apres a edité avec un mauvaise manipulation?)
Je vois sur Sakia, la capacité de copier QUE le cle public et aussi a copier le cle public avec CRC.
Si tlm utilise le QR code, il y a deja « error-correction » et moins de chance d’un mauvaise manipulation par l’utilisateur. Mais, d’utiliser base58 au lieu de base64 (ou un autre plus compacte) pour le cle public, j’assume qu’il y a, au debut, l’intention pour l’utilisateur a enrigistrer par main sur papier ensuite a taper le clé public avec le clavier
Si il n’ya a pas des discusions historique pour ne pas incluire « error-detection » par defaut…est-ce que peut etre une bonne idée de visioner un moment dans le future ou silkaj/sakia/cesium et meme duniter utilisent par default des expressions d’un cle public toujours avec CRC? (style sakia cle public avec CRC… ou c’est facile d’intentifier grace a « : » apres le cle public)?
Oui, suite à ces deux cas de transactions perdues, je pense que l’affichage <pubkey>:<checksum> devrait devenir un comportement par défaut de tous les clients Duniter.
Les trois clients gèrent le fait d’entrer les clefs pub avec le checksum, il y a un peu de modif à faire pour l’affichage.
Cesium et la future version de Silkaj utilisent le séparateur :, je crois que Sakia également, donc il ne derait pas y avoir de souci ?
En cherchant comment implémenter la vérification du checksum dans ĞMixer (je me suis basé sur le code de Silkaj) j’ai remarqué qu’il ne semblait pas permettre d’afficher le checksum. Une recherche rapide dans le code de Sakia n’a rien donné non plus, et je ne vois rien dans Cesium.
Je viens de l’implémenter dans natools, chaque pubkey entrée est vérifiée et on peut avoir le checksum d’une clé :
Avec tout ça, 17 June ont été débité d’un compte qui sont arrivé à un endroit bien identifié mais pas visible par le destinataire.
Qui peut déplacer cette somme vers la bonne désignation du compte destinataire ?
Personne d’autre que le propriétaire du compte qui a reçu les Junes. Si une faute de frappe a envoyé les Junes vers un compte au hasard, vous pouvez considérer ces Junes comme perdues. Désolé, mais dans la June, vous êtes responsables de vos Junes, il n’y a pas un tiers qui peut corriger vos erreurs en ayant accès à tous les comptes. Ce qui, quand on y pense, est un pouvoir bien trop fort qui renforce le besoin d’utiliser la June.
Dans la June, vous seul avez le pouvoir sur vos compte, pour simplifier : les clefs de vos coffre-fort. Et un grand pouvoir nécessite de grandes responsabilités, comme ne pas perdre ses clefs (sinon le compte est inaccessible à jamais) et ne pas envoyer de June sur un numéro de compte non vérifié.
Pour vérifier un numéro de compte, envoyez une June dessus et demandez à son propriétaire de vous la renvoyer. S’il y a un problème comme ici, alors on recommence avec le vrai numéro de compte et si la June est renvoyée on envoie la somme convenue.
Les logiciels clients doivent harmoniser la façon dont ils affichent les numéros de compte (si possible le numéro suivi par :xxx où xxx est une empreinte du numéro de compte qui permet de voir rapidement si le numéro est bien sans erreur de frappe). Un chantier pour la rentrée !
