Discussions sur les solutions pour s’assurer que les virements n’atterrissent pas sur des mauvais comptes.
C’est un condensa, un hash de la clé publique. Si une erreur est faite dans la clef publique, le hash de trois caractères ne validera pas la clé. Ça ne vérifie pas qu’il s’agit d’une clef publique utilisée.
Ça se présente de cette manière d’un point de vue du code et de la CLI :
pubkey!checksum
1 Like
C’est un condensa, un hash de la clé publique. Si une erreur est faite dans la clef publique, le hash de trois caractères ne validera pas la clé. Ça ne vérifie pas qu’il s’agit d’une clef publique utilisée.
Ok, et pour valider l’utilisation effective de la clef publique, n’est-il pas possible d’indexer quelque part (Cesium+ ?), l’ensemble des clefs publiques utilisées (récupérée et synchronisé depuis la blockchain) pour pouvoir vérifier rapidement ?
Et si je veut verser des G1 sur un compte portefeuille encore vide ? je ne l’ai “créé” nul part. Une telle vérification devrait être optionnelle sinon impossible de verser des premières G1 sur un “nouveau” portefeuille.
Et si je veut verser des G1 sur un compte portefeuille encore vide ? je ne l’ai « créé » nul part. Une telle vérification devrait être optionnelle sinon impossible de verser des premières G1 sur un « nouveau » portefeuille.
Je vois, et ne peut-on pas imaginer enregistrer un évènement de création de compte, à la création, dans la blockchain ? Comme cela, même vide, la clef publique est présente et donc vérifiable.
Avec pourquoi pas une expiration (comme c’est fait pour l’adhésion) au bout d’une période (1 an? ) si le compte n’a jamais eu de transaction (=> révocation).
Non, faut minimiser ce qu’on inscrit dans la blockchain, en plus ça complexifierai le protocole pour rien. Ce n’est pas a la blockchain de gérer ça.
En plus ce n’est pas kiss, ta proposition est gourmande en stockage et en requêtes, les checksum sont zero-cost en stockage et en requêtes 
Non, faut minimiser ce qu’on inscrit dans la blockchain, en plus ça complexifierai le protocole pour rien. Ce n’est pas a la blockchain de gérer ça.
Ça se discute, une blockchain c’est un registre, donc cela enregistre des événements. Créer un compte, c’est un événement.
On enregistre bien les révocations et exclusions à l’heure actuelle, alors pourquoi pas les créations ?
En plus ce n’est pas kiss, ta proposition est gourmande en stockage et en requêtes, les checksum sont zero-cost en stockage et en requêtes
Je ne vois pas en quoi cela est gourmand. Exemple:
{
.../...,
"new_accounts": [
"1EC9WGJoEiQyyRc6bcXFHxvZEtPgJMQUt4LvvqLGsmuE",
"59JpfrGkoHJWtumeu7f97fbAxkvaHYVQBNo5GszNs61Z"
],
.../...
}
C’est bien moins gourmand qu’une transaction et ça n’arrive qu’une fois par compte.
De plus derrière si c’est indexé par un ElasticSearch (comme Cesium+), c’est très rapide à rechercher, c’est fait pour ça (moteur de recherche)
Après oui, un checksum c’est zero-cost en stockage et en requêtes, mais ça ne contrôle pas la réelle existence du compte.
La blockchain ne doit enregistrer que ce qui est nécessaire et suffisant au fonctionnement de la monnaie. Tout le reste peut être stocké ailleurs.
Ajouter de nouvelles donnés dans la blockchain a des conséquences très lourde pour tout le réseau, on ne doit le faire que si l’on a pas d’alternative. Ce que tu demande peut être stocké ailleurs, et en plus il y a des alternatives.
Non y a aussi la requête dans l’index pour savoir si le destinataire saisi est valide, avec les checksum il n’y aucune requete a faire. Il y a donc bien un coût supplémentaire a chaque transaction, pas seulement lors de la “création” d’un comtpe.
Ça protège des erreurs de saisie, donc ça répond au besoin. La probabilité de tomber par hasard sur en checksum toujours valide par erreur de saisie est extrêmement faible (de l’ordre de 1 chance sur 20000 avec le checksum proposé par Tortue et de une chance sur 4 milliards avec des adresses au format bitcoin-like).
Oui, je n’ai pas dit que le coût était nul, juste faible, de mon point de vue (sans compter que Cesium peut avoir du cache).
Mais bon passons. Le checksum pourquoi pas, si je comprend bien cela signifie que l’identifiant d’un compte à saisir pour faire des virements ne se limiterait pas à la clef publique, il serait composé de [clef_publique]![checksum], par exemple ?
Oui, c’est un format possible et c’est celui actuellement utilisé par Silkaj. On pourrait rendre obligatoire l’usage du checksum.
Avant c’était [clef_publique]:[checksum]
2 Likes
Afin d’éviter d’envoyer de la monnaie sur un mauvais compte, je ne sais plus qui avait proposé que si A envoi de la monnaie sur le compte B, ce dernier doit accepter la transaction. Et si il ne le fais pas dans un temps donné, la monnaie revient sur le compte A.
Est-ce réalisable, souhaitable ?
1 Like
L’éventuel cache d’un client (et même le fait de citer elastic search) ne comptent pas quand on parle d’inscrire des choses en blockchain.
Tu penses trop coté clients et pas assez coté serveurs blockchain, tout ajout de donnée en blockchain impacte lourdement les serveurs blockchain, leurs API (GVA, WS2P), leurs protocoles, etc … ça impacte également les perfs (traitement de plus dans le protocole) et le stockage de toutes les machines des utilisateurs de Duniter (et futures implémentations de serveur blockchain). Ce n’est pas un “cache” coté client qui vas minimiser quoi que ce soit.
J’ai ouvert un sujet pour discuter de ce sujet de sécurisation de la destination des transactions: Sécurisation des virements - Validation de la clef publique de destination
Avis aux modérateurs pour déplacer les posts correspondants 
Oui et le protocole DUBP le permet déjà. Il n’y a que du dev a faire coté client.
Il suffirait de généraliser les transaction vers SIG(B) || (CSV(500000) && SIG(A)) par exemple 
1 Like
Afin d’éviter d’envoyer de la monnaie sur un mauvais compte, je ne sais plus qui avait proposé que si A envoi de la monnaie sur le compte B, ce dernier doit accepter la transaction. Et si il ne le fais pas dans un temps donné, la monnaie revient sur le compte A.
Est-ce réalisable, souhaitable ?
C’est probablement @Maaltir qui t’en a parlé, il m’en a parlé au dernier apéro.
Personnellement je ne suis pas favorable, je trouve que cela complexifie trop l’expérience utilisateur.
Je préfère la solution de checksum mentionnée par @Moul ;), qui me parait suffisante dans un premier temps.
Ça pourrait être présenté comme un type de paiement différent, on aurait :
- paiement classique
- paiement sécurisé
Avec une recommandation ou/et obligation de privilégié les paiement sécurisés uniquement pour les très gros montants par exemple
une tel fonctionnalité aurait permis d’éviter l’erreur à 13000 G1 lors des RML14 
5 Likes
Dans ce cas, j’approuve
1 Like
Il me semble qu’il y a deux besoins différents, qui doivent être adressés de manière différente :
- Le besoin de prévenir des erreurs de saisie de la clé publique du destinataire → solution le checksum
- 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
1 Like
Cesium reconnais déjà le format pubkey:checksum définit par @Tortue.
Dans les QRCode scanner, l’annuaire, le login, etc.
Le controle du checksum est effectué, quand le pattern pubkey:checksum est détecté.
Exemple, dans “Annuaire” :
Il manque, en revanche, l’affichage de ce checksum dans :
- les QR Code générés (la lecture le prend déjà en compte, s’il est présent)
- les champs où sont visibles les clefs publiques en entier (notamment utilisé par les copier/coller).
- les clefs publiques tronqués ? En plus des 8 premier caractères, on pourrait mettre le checksum à la fin (séparé par un caractère).
2 Likes
Oui l’idéal serait que le checksum soit systématiquement affiché, pour que l’utilisateur le saisisse avec.
Idéalement, il faudrait que la pubkey sans checksum n’apparaisse jamais nul part