La notion de délais peut être intéressante en effet, je dirais plus particulièrement avec l’usage suivant :
quand le code du verso est scanné pour la première fois :
immédiatement, le réseau est notifié de la demande, ainsi que de la clef publique où verser le montant du billet (clef publique chiffrée pour rester confidentielle le temps du compte à rebour). Cette action déclenche un compte à rebours de 7 jours.
durant ces 7 jours, le scan aussi bien du QR code de vérification que de celui du verso déclenche le versement vers un compte aléatoire (reviens à détruire la monnaie du billet).
Si l’on peu implémenter ça techniquement, d’un point de vu algo, ça me semble effectivement apporter un gros gain de fiabilité, puisqu’un fraudeur a peu de chance de pouvoir récupérer la valeur d’un billet dupliqué.
Ceci dit, ça n’enlève que l’intérêt d’encaisser un billet dont on a fait des doubles ou une photo. ça n’enlève pas l’intérêt de faire des doubles tant que personne ne s’en rend compte et les échange sans les encaisser (mais l’analyse statistique se chargera d’en réduire l’ampleur de diffusion).
Et même si ça peut être un mécanisme de sécurité intéressant, il me semble rajouter une complexité de compréhension supplémentaire qui peu refroidir l’utilisateur quand au fait d’accepter un billet papier si, quand il est marqué valable le jour 1 il n’est pas sur de pouvoir en transférer la valeur sur son compte s’il déclenche le mécanisme aussi-tôt après.
Exemple :
Sans ce mécanisme de délais :
On me tend un billet de 1000 Ǧ1
Je fait le scan de vérification, si tout va bien, je l’accepte
Je l’encaisse numériquement immédiatement après, pour être sur d’avoir la valeur correspondante sur mon compte. (S’il y a le moindre problème, j’ai encore le fournisseur de billet devant moi pour lui dire que sont billet est chiqué).
Avec le mécanisme de délais :
On me tend un billet de 1000 Ǧ1
Je le refuse car si un double est en circulation, mais depuis suffisamment peu de temps pour que ça ne se voit pas statistiquement, il sera vu valable mais ne pourrais être encaissé numériquement puisque re-scanné durant les 7 jour de quarantaine.
Conclusion on réduit l’appât du gain à encaisser le billet en douce, mais on réduit la confiance dans le billet en usage légitime.
Alternative :
durant les 7 jour de délais, un scan de vérification alerte qu’un processus d’encaissement numérique est en cours et invite à revendiquer le billet depuis un compte membre (fournir une clef publique membre pour encaisser numériquement le billet et signer la demande pour prouver qu’on est titulaire du dit compte membre). De cette façon, le montant du billet est transféré au premier compte membre saisi durant la période de vérification, on sais donc vers qui se retourner si l’on dispose du billet vidé de sa valeur entre les main.
Et dans ce cas si l’on reprendre le scénario du billet de 1000 Ǧ1, je l’accepte et immédiatement, je l’encaisse numériquement avec mon compte membre.
Ceci dit, on peut du coup aussi simplifier tout ça en n’autorisant l’encaissement numérique que vers un compte membre, et basta.
Je suis assez dubitatif sur l’usage que pourraient avoir ces billets. Ce sont des des bouts de papiers que les utilisateurs peuvent imprimer, mais qui ne peuvent être passés qu’a une seule personne avant de devoir être “numérisés”. On est loin de l’usage pratique d’un billet pouvant s’échanger de mains en mains sans passer par un support numérique
Et du coup les commerces (qui ne sont donc pas des comptes membres) ne peuvent pas accepter des billets ?
Je suis aussi assez dubitatif sur l’usage de billet d’un montant important, sauf éventuellement pour invisibiliser des transactions intermédiaires (mais avec le risque d’encaissement numérique par un intermédiaire).
Mais montant important est subjectif…
Si, mais au choix :
pas les encaisser numériquement (ce qui me semble très limitant pour un commerce)
passer par un membre pour les encaisser (comme quand une personne fait une avance de frais et se fait rembourser par une personne morale ensuite. Là, c’est pareil mais dans l’autre sens.
Après, avec le mécanisme de délais, on peut autorisé l’encaissement vers un compte non membre, mais mettre priorité au premier compte membre encaisseur en cas de conflit. (voir autoriser l’encaissement avec délais vers un compte non membre et l’encaissement immédiat vers un compte membre).
Et la recommandation de conserver ses fragments de billet pour montrer sa bonne fois en cas de conflit.
PS @nanocryk tu vois comment faire ce système d’encaissement avec délais sans smart-contract ni tier de confiance centralisé ?
Pour contextualiser, j’ai 2 ans derrière moi de formatage au “trustless spirit” inculqué par bitcoin, c’est fondamentalement l’inverse de la confiance.
On part du principe que le réseau offre la confiance, et qu’on ne met aucune confiance dans l’utilisateur.
En pratique, j’ai offert à plusieurs reprise de PaperWallet garni de bitcoin à des proches, et ils ont confiance en moi quand je leur dit, “la clé privée n’est pas compromise”, sous entendu, tu peux me faire confiance sur le faite que je n’ai pas gardé de copie de la clé, et que tu en es le seul propriétaire.
Ceci étant dit, j’ai une tendance à chercher le coté trustless du billet, avec un protocole qui permettrai d’avoir la garantie que le billet n’est pas compromis.
@1000i100 tu as placé la confiance en l’utilisateur assez haut dans l’usage du billet, il y a forcément un juste milieux. Surtout avec une toile de confiance ne l’oublions pas.
Je propose ces axes pour contraindre la confiance
Seul un compte membre peut produire un billet, ce qui garantie le point de départ.
Peut être laisser le choix à l’utilisateur entre deux modes : un mode “confiance”, avec un retrait simple via la clé privée pour usage immédiat.
Un mode “sécurisé”, avec le mécanisme de delais à la délivrance des fonds.
Laisser le choix permettrai de voir ce qu’in fine les utilisateurs préfèrent.
Si la confiance est de mise, ou la méfiance ? ^^
Intellectuellement, j’aime bien l’idée de laisser le choix à l’utilisateur. D’un point de vu développement, moins, vu qu’il faut coder chacune des versions.
J’aime bien aussi le principe de non ingérence : pas besoin de modifier le protocole Ǧ1 pour gérer les Ǧ1Billets. C’est d’ailleurs ce qui permet de développer G1Billet alors qu’il est loin de faire l’unanimité parmi les dev de la Ǧ1. Du coup, ce qu’on confit au réseau, techniquement, il faut voir à quel réseau on le confie.
Si c’est confié au réseau fédéré de statistique de scan de Ǧ1Billet, ça marche.
S’il faut ajouter des choses en blockchain, faut voir si c’est possible ou non. Avec ce que @nanocryk nous prépare, ça devrais le devenir (possible), mais pour l’instant, j’en suis moins sur.
Je suis tout à fait d’accord, et pour l’instant je ne trouve pas solution pour avoir un billet “trustless”, et ce pour 2 raisons :
Le créateur du billet connaît la clé privée et peut la garder.
Les billet sont duplicables, et rien ne permet de faire la différence entre l’original et la copie. Quelqu’un peut très bien “ouvrir le billet” pour avoir accès à la clé, puis en imprimer un nouveau identique et le scéler. Il connaît alors la clé et possède un billet “non compromis”. Il peut très bien attendre un moment avant de “demander l’autorisation” au réseau de vérification, temps pendant lequel il n’est pas possible de savoir s’il y a eu duplication.
Pour avoir du trustless, il faudrait donc trouver une solution à ces 2 points. Sinon, il faut faire appel à un tier de confiance.
Ici c’est surtout inhérent à la nature duplicable du billet, ce que fygg ne pourra pas changer. Par contre il pourrait permettre d’implémenter ton idée de registre des billets déverrouillés à l’intérieur du système.
Avec les billets en UNL, non-seulement les procédés de fabrications sont coûteux, mais surtout le risque est partagé par tous : un faux-billet (réussi) augmente la masse monétaire, et c’est juste l’ensemble de la valeur de la monnaie qui décroit, et non un billet en particulier.
J’avais croisé un économiste qui disait “on s’en fiche des faux-billets, tant qu’ils ne sont pas trop nombreux”. Le problème avec le procédé actuel c’est qu’un billet compromis vide l’original. C’est pour ça qu’il ne faut pas confondre “billet” et “paper-wallet”.
Une solution pourrait être qu’un organisme de change fabrique des billets et propose de les convertir dans un sens ou dans l’autre, mais en décentralisé ? J’avoue que je ne sais pas.
On pourrait avoir des organismes qui impriment ces billets, et qui sont responsable de générer et d’oublier les clés privées. Si plusieurs organismes se font confiance mutuellement, ils peuvent se fédérer et accepter les billets et “supporter” les billets des autres.
Mais comme tu dis, le procédé de fabrication des billets est couteux, et je ne pense pas que ça en vaille la peine alors que l’on a un outils numérique trustless à la base. Par contre il pourrait être possible de produire des petites cartes a puce (style carte de crédit) qui permettent de gérer des clés privées et recevoir des documents à signer, les clés ne sortant jamais de la carte et ne pouvant pas être extraites (pourquoi pas protégées par un code pin). Ca peux être couteux à lancer, mais l’avantage c’est que ce n’est plus un support à usage unique.
Les cartes à puces me semble un option très intéressante aussi, mais c’est autre chose, pour un usage différent, du coup, pour parler carte à puce, je vous renvoi ici :
Bonjour.
Je suis tombé sur la video: RML11 Douarnenez Ğsper et Ğ1billet @1000i100.
Et je souhate faire des propositions pour augmenter la securité des billets si le sujet est toujours d’actualité.
Ma première proposition est de donner le nombre de fois ou le billet a été scanné lorsqu’il est scanné par le QR CODE sur écran.
Ma seconde c’est de noter les numero de personne sur chaque billet c’est a dire , l’emetteur notera 0 , le 1er recepteur 1 , le 2eme 2 ect …
Ma 3eme proposition c’est que chaque personne note le nombre de fois qu’il a scanné le billet en face de son numero.
Sinon a la place du 3 on demande de scanner avec un logiciel spécifique qui vérifie:
le nombre total de scan a l’acquisition du billet
-lors d’un re-scan (lors d’un achat) si le conpteur local est different du compteur global il faut encaisser immédiatement.
Le projet est toujours dans les cartons, mais je suis entrain de bosser sur d’autres projets qui vont me servir pour Ǧ1Billet tout en pouvant servir indépendamment sans que Ǧ1Billet soit prêt.
Il est en effet déjà prévu de collecter l’info pour analyse statisitque, donc l’afficher au scan, pourquoi pas oui.
Que ce passe-t-il si a un moment le billet passe de main en main sans qu’il y a de connexion internet, ou sans qu’il y ai de smartphone, bref, sans scan ?
Il me semble important de garder ce cas d’usage en tête car même s’il est moins sécure qu’en scannant, il me semble indispensable à la fluidité des échanges et à l’inclusivité de ceux laissé pour compte par la fracture numérique.
ça va vite prendre de la place et être plus fastidieux à manipuler que de faire un virement numérique… non ?
Je comprend le besoin de sécuriser, mais il me semble indispensable de garder en tête que c’est une surcouche facultative à la Ǧ1, et du coup, si elle deviens plus compliqué d’usage que l’original, elle perd tout intétêt fonctionnel.
Au contraire, avoir une grande fluidité d’usage, avec une sécurité moindre, (donc reposer encore plus sur la confiance), mais avec des statistique permettant de se faire une idée de si la confiance est justifié ou non me semble répondre au besoin de multiple situation à connexion non systématique.
Je vais essayer de réexpliquer jme suis mal exprimé.
Ma 2eme proposition de noter en gros on a combien de personnes depuis l’emeteur jusqua l’utilisateur courant.C’était de me dire de la meme maniere que la toile de confiance , si je connais quelqu’un qui connaisse quelqu’un qui a créer le billet peut etre que j’aurais plus confiance qu’un billet utilisé plus de 10fois .
du coup c’est une sécurilté qui peut se faire sans internet de juste noter un numéro .
Et assez simple vu que c’est une addition par 1 a chaque billet qu’on recoit.
Cependant il est vrai que j’ai admis l’hypotèse d’utilisation du meme billet 5 fois c’est peut etre trop peu …
Combien de fois penses tu qu’un meme billet sera utilisé ?
Ma 3eme proposition est conjointe a la 1ere permet juste de détecter presque instantanément si il existe un double.Enfin si il y’a un scan a la possesion et un scan la sortie.On peut automatiser ma 3eme proposition dans le logiciel de scan.
Je donne un exemple si A crée 2 memes billet et les dépense B et C
au 1er scan de B le billet montre scanné 10 fois donc billet securisé
au 1er scan de C le billet montre scanné 11 fois donc billet securisé
si B ou C rescan ca dira instantanément qu’il existe un autre billet et qu’il faut encaisser.
Ma proposition permet de détecter beaucoup plus vite les autres billets.
En fait si tout le monde fesait un scan a l’entrée et sortie avec ma proposition ca pourrait permettre de bloquer tous les doubles a partir du moment ou le meme a été scanné ailleurs .
Ca permet d’augmenter le risque sur le fraudeur et limiter les échanges fait avec ces billets.
Es-ce que ca serait plus difficile avec cette proposition je pense pas ca serait intégré dans le logiciel du lecteur QR code. La seule complexité serait de changer de mode acquisition quand on recoit les billets et de passer en mode vérification quand on paye un autre.
