Je suppose l’implémentation suivante : lorsque je crée un compte simple porte-feuille à la fin de la procédure (taper plusieurs fois les identifiants) on me demande de télécharger le « fichier vidange révocatoire »
-Je perds mes identifiants
-Je dépose le fichier vidange révocatoire pour vider mon compte (même procédure que l’actuel fichier de révocation)
- Le solde de mon compte est ventilé sur 10 comptes : le compte des développeurs, le compte remuniter et 8 comptes membres tirés au sort
Je peux consulter les 8 transactions effectuées sur le compte perdu pour relever les pubkey des membres et les contacter pour leur demander de bien vouloir me restituer sur une autre pubkey le montant qu’ils auront décidé (suivant s’il sont bien disposés ou pas). Si les 8 sont compréhensifs et très gentils je récupère 80% du solde précédemment perdu.
Cette mécanique peut aussi s’appliquer à un compte membre qui dans ce cas sera automatiquement révoqué (d’où mon intitulé : fichier vidange révocatoire)
Ainsi on pourrait limiter la perte de junes dans des comptes fantômes (inaccessibles)
Votre avis?
Il est possible d’inclure un document de transaction dans le fichier, cependant la transaction ne pourra vider que les sources présentes au moment de générer le fichier. Les DUs créés et transactions reçues après la génération du fichier ne pourront pas être vidangés.
Ensuite, le choix aléatoire ne peut se faire qu’à la génération du fichier.
Cela nécessite donc de modifier le protocole (à moins que j’ignore un truc fantastique), ou de faire avec ces limitations.
En tout cas, le protocole ne doit pas privilégier une clé publique, donc l’envoi au compte développeurs ne doit pas être obligatoire (pas en dur dans le protocole).
Peut-être est-il possible de faire ça sans implémenter ce comportement, mais génériquement en améliorant le système de sources ?
1 Like
Un changement de protocole a été discuté pour que les transactions soient valables indéfiniment. Mais ce n’est pas pour tout de suite.
Ceci permettrait à un logiciel client d’avoir ce comportement :
- un compte “sauvegarde” est paramétré (ou plusieurs)
- à chaque utilisation du client pour une signature, le client crée des TX pour envoyer toutes les sources disponibles à cet instant vers le compte “sauvegarde”. (une TX par source), et les conserve, éventuellement chiffrés.
- si les identifiants sont perdus, il est possible de publier toutes ces TX et de verser les sources encore disponibles vers le compte de sauvegarde.
- les sources arrivées sur le compte depuis la création des TX de sauvegarde ne seraient pas récupérées.
… encore faut-il se souvenir des identifiants du compte “sauvegarde”. Le compte d’un.e ami.e me semble approprié. Et que se passe-t-il si les transactions conservées sont perdues ?
Je vois un cas d’usage, c’est le cas d’un testament : le testament contient le code de déverrouillage des TX conservées pour les envoyer vers le compte de l’huissier désigné auparavant. Ceci permettrait de récupérer une partie de la monnaie sans révéler les identifiants du défunt.
L’éducation populaire sur ce qu’est une monnaie sur Blockchain, et l’apprentissage des outils appropriés pour ne pas perdre ses identifiants (gestionnaires de mots de passe, WIF/EWIF imprimé en QR-Code), me semble bien plus adaptée.
2 Likes