Je propose ici un procédé “anonyter” qui peut pourrait être algorithmiquement géré de type “remuniter” :
Envoi à la clé de Anonyter (ou une des nombreuses clés disponibles de Anonyter) de 100 Ğ1 (donc clé publique émettrice connue du programme) + document contenant la clé cible, signé par l’émetteur.
Le programme attend un temps défini (exemple 10 jours), pour se déclencher Ssi 10 envois similaires ont été effectués par 10 émetteurs différents.
Si les 10 émetteurs différents sont atteints dans le temps imparti, envoi des Ğ1 aux clés cibles (déduits d’une commission de 0 ou X Ğ1, peu importe).
Si les 10 émetteurs différents ne sont pas atteints au bout des 10 jours : renvoi des Ğ1 aux émetteurs.
Anonyter pouvant gérer un grand pool de clés d’anonymisation, on peut ainsi encaisser un grand nombre de Ğ1.
Pour rendre tout ça robuste, il faudrait s’appuyer sur les mécanismes de conditions de transferts, permettant leur annulation depuis n’importe quel parti (envoyeur ou receveur). https://duniter.org/en/transactions-0-2-overview/
Il y’a un problème dans le fait de tout automatiser en passant par la blockchain comme proposé içi…
Car même chiffré par un alogorithme, cette information se retrouve inscrite définitivement dans la blockchain et donc finira par pouvoir être cracké au bout d’un moment.
La force finalement du service “à la main” de @vincentux est le fait de communiquer la clé anonyme par un autre canal que la blockchain (içi les messages chiffrés de Césium, qui pourront disparaitre un jour).
Le mieux est encore de diversifier les canaux (dispo, frama, …)
Tout est hackable, finalement. Qui envoie une équipe de torture chez @vincentux pour lui faire cracher le morceau?
En fait, ça fait aussi un moment que je réfléchis à ça, et il y a des contraintes vraiment contradictoires à prendre en compte :
sécurité de l’anonymisation, à savoir protection maximum des données, ce qui implique chiffrement, limitation des supports de stockage d’information dans l’espace et dans le temps,
fiabilité du système, qui implique de la redondance en terme de stockage et de ressources (en cas de panne, catastrophe naturelle et autres) ainsi que de l’information « en clair » et potentiellement après l’opération d’anonymisation pour pouvoir vérifier ce qui s’est passé en cas de litige.
Difficile à concilier de manière parfaite, tout ça !
Non il n’y a pas besoin de publier la commande entre un client et son fournisseur dans la blockchain. C’est précisément ce que fait vincentux, d’ailleurs.
La force d’un robot aussi, c’est qu’il peut inclure dans son code le fait d’oublier un contrat passé. Ce qui permet une anonymisation très forte.
Ha! Et alors quel est le “document contenant la clé cible” dont tu parle et par quel moyen le service Anonyter le récupérerais dans ce cas? (Dans le cas d’un service automatisé ne faisant pas intervenir un humain)
Bah oui merci, c’est exactement ce que je démontrait…
Mais sans humain dans le pipeline, je ne vois pas comment ne pas laisser une trace quelque part?
Qu’Anonyter soit un humain ou un robot, c’est pareil non ? Par exemple un site web avec un formulaire qui est signé par la clé cliente demandant l’anonymisation. Ce formulaire n’est retransmis qu’à Anonyter.
J’ ai un mécanisme en tête qui utilise la fonction de lock XHX, qui permet de mettre un “mot de passe”
Anonyter signe un document avec comme output :
SIG(clé public anonyme pour recevoir les fonds ) && XHX(sha256(pass que seul le membre connait))
Anonyter renvois ce document signé au membre,
qu’il est fortement recommandé d’enregistrer quelque part sur son disque dur
et que sous certaines conditions, le membre peut valider en blockchain
→ des conditions critiques pour recuperer sa monnaie au cas où le systeme n’a pas suffisament de “personnes qui souscrit” au service dans un pool de transactions pour effectuer l’opération dans un laps de temps d’une semaine a partir de l’instant où il y a un 1er enregistrement dans le dit “pool”
j’ai plusieurs point en tête et j’y vois de gros avantage du point de vu – administration du service,
les clés de la signature de Anonyter ne deviennent plus critique notamment…
de maniere a ce que la responsabilité est reporté sur le membre souhaitant faire l’operation,
il devra être vigilant
