Bien vu 
FAQ Mise à jour. Ca me semble bon là : https://duniter.org/fr/wiki/faq/#jai-perdu-mes-identifiants-ou-je-souhaite-changer-mon-pseudonyme-ou-ma-cle-privee-que-puis-je-faire
Oui!
Ce n’est pas simple de prévoir toutes les configurations et erreurs possibles.
Merci.
En fait non le certificat de revocation n’st lié qu’a un seul compte, pour savoir lequel il faut regarder dans le fichier (c’est de l’ASCII) la valeur du champ IdtyTimestamp qui correspond au blockstamp de publication de l’identité, et comme tes deux identités ont un blockcstamp différent tu sais laquelle sera révoquée par ton fichier de révocation 
Je suis d’accord mais comment revoquer le deuxième compte qui a les mêmes identifiants? En modifiant le fichier de révocation à la main?
J’ai demandé de révoquer le IdtyTimestamp: 32553. Il me reste à révoquer le IdtyTimestamp: 32580 puisque j’ai cree un autre compte!
Les deux comptes sous stephane_jouin sont en attentes de révocations.
Non car la signature du document ne sera plus valide, mais en fait ce que je te proposait hier c’était de révoquer un seul de tes 2 comptes et de garder l’autre, je ne pensais pas qu’entre temps tu en créerai un 3ème 
Je te confirme que tes deux comptes stephane_jouin sont bien revoqués, je le voit dans la bdd d’un de mes nœuds, donc c’est bon 
Ouf! Merci.
Bonsoir,
Mon compte membre “stephane” étant révoqué, est-il possible de l’utiliser en simple porte feuille?
Il me semblait que cela était possible.
Oui, et ce serait possible même s’il n’étais pas révoqué d’ailleurs. L’usage d’une clé publique pour la monnaie est totalement indépendant de la partie identification/toile.
@elois j’ai une question :
Nous pouvons émettre 100 certifications par identité ou par clé publique ?
D’autre part je viens de découvrir une difficulté sous césium : lorsque un compte a 2 identités avec un pseudo identique et qu’il possède 4 certifs sur une identité et 0 sur l’autre, dans la vue mon compte on peut basculer d’identité mais quelle que soit l’identité mais lorsqu’on passe dans la vue des certifications alors on voit toujours la même quelle que soit l’identité dans laquelle on a préalablement basculé. exemple pseudo “mateo”
Si plusieurs identités sont déclarés avec la même clé publique, 1 seule pourra s’écrire en blockchain, et dés l’ors qu’elle est écrite, toutes les autres identités avec la même clé publique deviennent invalides.
De plus seule une identité devenue membre peut émettre des certifications, ta question n’a donc pas de sens
@elois et quid du problème de la vue des certifications reçues et émises toujours réglée sur la même entité ?
@jardin il ne faut jamais créer plusieurs identités sous la même clé, c’est source ne nombreux problèmes, la personne concerné devrait revoquer toutes ses identités et en créer une seule nouvelle sous une nouvelle clé (donc pass différents).
Je vais essayer de décrire ce qui s’est passé après réflexion-analyse-enquête :
Le césium g1.duniter ne répondait pas donc le compte fut créé sur le cesium g1.le-sou.org
Quelques heures plus tard en allant sur g1.duniter cesium a dit que l’identité n’étais pas publiée.
En fait ce cesium n’arrivait pas à joindre le noeud et a donc proposé une bascule sur le noeud inso ovh.
Et ce noeud est resté désynchronisé durant de longues heures, c’était il y a 4 ou 5 jours quelques jours.
Si nous avions pensé que la synchronisation pouvait être aussi longue, nous n’aurions pas republié l’identité.
Mais avec la confusion et la fatigue … …nous avons raisonné comme des utilisateurs.
Je soulève donc à nouveau le problème déjà soulevé : faut-il raisonner développeur pour qu’il n’y ait pas de problème ? ou faut-il améliorer soit, le processs, soit la communication à la création de compte ?
@elois alors a quoi sert cette possibilité technique de créer plusieurs identités ? Ne serait-il pas judicieux de ne prévoir qu’une entité par clé publique dans le protocole ?
@jardin c’est déjà le cas… tu crois vraiment que nous aurions fait exprès pour compliquer l’usage ??
Il te faut comprendre les bases d’un fonctionnement acentré P2P : le réseau est nécessairement incomplet et incohérent : donc tant qu’une donnée n’est pas en blockchain il est impossible d’être parfaitement synchoniser ne serait-ce que sur l’existance meme de cette donnée.
Ainsi il est impossible d’empêcher le cas : “création de plusieurs identités sous la même clé publique”. Après c’est aux dev des clients de réfléchir a comment présenter ça de façon user-friendly, si tenté que ce soit possible 
1 Like
@elois, je ne vois vraiment pas pourquoi tu penserais que je pourrais croire que vous auriez fait exprès de compliquer l’usage… mdr
J’ai déjà compris ce que tu expliques, je pensais plutôt que en quelques heures la blockchain pourrait peut-être se synchroniser et ne garder que la première entité. Mais ça impliquerai que les identités soient inscrites dans la blockchain avant de devenir membre co-créateur.
Et effectivement j’ai pensé qu’il y avait un soucis dans les logiciels clients mais existe-t-il des données de liaisons précises entre les clé publiques, uid, identités et certifications permettant ce “user-friendly” ? Par exemple voir précisément sur quelle identité sont dispatchées les certifications et pouvoir certifier une clé sur l’identité de son choix afin d’éviter de devoir pratiquer la révocation avec ce que cela implique dans le choix du pseudo et de la clé.
Voilà, ce ne sont que des questionnements et des pensées, ne crois pas que je te prenne pour une bille, et j’espère ne pas te faire perdre ton temps 
Donc de pouvoir spammer la blockchain de façon illimitée puisque les identités peuvent etre générés a l’infini, impensable…
je n’ai pas dit qu’il n’y en avait pas, je dit simplement que ces cas d’identités multiples ne sont pas évitables, après libres au client de gérer ces cas comme il l’entendent, un client peut très bien détecter qu’il y a plusieurs identités et proposer au certificateur de choisir laquelle certifier, mais encore faut t’il qu’il est reçu toutes les identités en question, et comme le réseau p2p est incomplet et incohérent par nature, le client ne peut pas te garantir qu’il n’existe pas d’autre identité qu’il n’aurais pas reçu. On peut prouver l’existence d’une identité (si on l’a c’est qu’elle existe), mais on ne peut pas prouver son inexistence…
Donc oui les clients son perfectible, mais même un client parfais ne pourra pas empêcher tout les problèmes.
J’ai bien une idée pour résoudre ce problème, mais ce sera pour le protocole v11
1 Like
En tous les cas, j’ai découvert que la double identité en question plantait mon sakia :
2 Likes