Sécurisation des virements - Validation de la clef publique de destination

Il me semble qu’il y a deux besoins différents, qui doivent être adressés de manière différente :

  1. Le besoin de prévenir des erreurs de saisie de la clé publique du destinataire → solution le checksum
  2. Le besoin de gérer le problème de l’envoi a la mauvaise personne (par copier/coller ou scan d’une clé publique qui n’appartiens pas a la bonne personne, que ce soit par inadvertance comme l’erreur a 13000G1 des rml14 ou par attaque de type phishing) → solution le paiment double check*.

Le paiment double check : pour une transaction A → B le logiciel client envoi les fonds avec les conditions (SIG(B) && HXH(code)) || (SIG(A) && CSV(5jours).
L’utilisateur ayant émis le paiement transmet alors le code au destinataire (oralement, par mail, par sms, qu’importe), ça peut être un code très court genre un code pin à 4 chiffres.

  • Soit le destinataire récupère les fonds dans les 5 jours à l’aide du code pin et tout le monde est content.
  • Soit le destinataire ne récupère pas les fonds (car les fonds se trouvent sur un compte qui n’existe pas ou qui n’appartient pas a la bonne personne), et l’émetteur peut alors récupérer a tout moment une fois le délai de 5 jours écoulés.

On peut évidemment remplacer 5 jours par n’importe-quel autre délai, ce n’est qu’un exemple.

Ainsi, “savoir si un compte existe” ne me semble pas être un besoin. Toutefois cela est déjà possible actuellement sans rien ajouter en blockchain, car par définition un simple portefeuille n’existe que s’il a déjà reçue au moins 1 fois de la monnaie.
Il suffit donc au logiciel client de vérifier si le portefeuille destinataire a déjà reçu au moins de la monnaie, et si tel n’est pas le cas d’afficher un message d’avertissement du genre “Ce compte n’a jamais eu aucune activité, vous vous êtes peut-être trompé de destinataire. Envoyez 1 G1 et demandez au destinataire de vous la renvoyer pour vérifier qu’il gère bien ce compte la, ou passez par un paiement double-check”.

Dans le cas particulier de Cesium, il peut même se baser sur les fiches profil Cs+ pour considérer qu’on compte “existe” s’il a une fiches profil Cs+.

Ce que je veut dire @bpresles, c’est que dans 99,99% des cas d’usage il a un moyen de répondre au besoin utilisateur sans ajouter quoi que ce soit en blockchain, et que c’est toujours ces pistes la qu’il faut explorer en 1er. C’est seulement en dernier recours, après avoir évaluer en long en large et en travers toutes les moyens de répondre au besoin utilisateur hors-blockchain, après avoir envisagé que le besoin utilisateur identifié n’est peut-être pas indispensable, c’est seulement tout ça que la question du stockage en blockchain peut éventuellement se posée.

C’est pour cela que ta proposition de rajouter une info en blockchain m’a parue extrèmement disproportionnée, j’espère que tu comprend mieux ma réaction :slight_smile:

1 Like