Revenant de congés dans une zone morte niveau internet, la question m’a été posé de l’utilisation de la Ğ1 dans ce genre de cas. Tout cela sans passer par un carnet de compte pour effectuer les transaction plus tard lors d’un accès internet.
Ayant déjà vu la possibilité d’imprimer des bitcoin, quel serait la marche à suivre pour faire de même acec la Ğ1 ?
Créer un portefeuille contenant une somme et imprimer les identifiants sur un billet pour les récupérer plus tard ? Comment s’assurer que ces identifiants ne soient connus que du possesseur du billet ? Un sceau qui valide l’intégrité du portefeuille papier ?
Un billet de 10 Ğ1 valant toujours 10 Ğ1 peux importe le moment où la transaction est effectué.
Il faudra par la suite imprimer des billets de 100, 1000 etc, en fonction de la valeur du DU pour coller à la réalité du marché.
Techniquement, que faudrait-il faire ? Est-ce une aberration ?
@1000i100 rapport a ton projet G1billet, j’ai eu idée, pour rendre trustless le billet en lui même.
Voici l’idée :
Sur la face recto du billet on ne change rien.
Sur la face verso un QR code (qu’on peut laisser éclaté ) mais qui si il est scanner ferai la chose suivante :
Faire une demande au réseau de la clé privée, ceci aurai deux effets immédiats :
1/ Donner la clé privée au propriétaire actuel
2/ Si qqun d’autre vérifie le billet, alors un message d’alerte lui dirait attention la révélation de la clé privée à déjà été demandé, nous vous conseillons de ne pas accepter ce billet qui pourrai être compromis.
Bien sûr une attaque du type, je scan le QR code, je paie, puis je récupère les coin est possible, mais cela implique de prévenir le réseau. Ce qui rajoute une étape, potentiellement dissuasive.
Je pense que la présence de la clé privée sous la forme d’un QRCode, avec par dessus un autocollant avec un motif rendant illisible la clé au travers, et qui laisse une trace visible quand retiré serait beaucoup plus sécurisé tout en permettant de voir si le billet est “potentiellement déjà dépensé” ou non.
l’autocollant sécurisé pourrais irrémédiablement laisser des traces sur l’original… mais pas sur une copie, du coup, ça me semble complexifier (effectivement en s’écartant de l’impression classique) sans un gain réel de sécurité.
En revanche, l’idée de “demander la clef privé au réseau” pourrais m’intéresser. Pas tel quel, mais en coupant la poire en 2 :
une partie de la clef privé sur le billet et seulement sur celui-ci
une partie de la clef privée, idéalement stocké en ligne sur réseau fédéré, avec un type de chiffrage dont le déchiffrage ne pourrais pas (ou très difficilement) passer inaperçu. Afin de pouvoir utiliser l’accès à ce fragment de clef privé comme un voyant “à encaisser/renumériser”
Intuitivement ça me semble améliorer la sécurité en effet.
En y réfléchissant plus, c’est pas sur que ça change quoi que ce soit.
Si je stock hors ligne quand j’ai le billet entre les main ce qui permet de faire la demande de la partie qui se trouve sur le réseau, (ou que je prend une photo du verso du billet pour faire simple), je pourrais faire exactement la même chose que si la clef privé était au verso.
Du coup, je vais aller me coucher en pensant à ça histoire de voir si une idée lumineuse me réveille.
Il y a là une piste très interessante. Je propose le protocole suivant :
On génère 2 paires de clés F (fonds) et B (billet)
On bloque des fonds en utilisant la clé publique de F
On chiffre la clé privée de F avec la clé publique B, et on envoie cette clé chiffrée sur le réseau
On inscrit la clé privée B ainsi que les 2 clés publiques sur le billet
Ainsi, la clé (chiffrée) sur le réseau ne peut pas être utilisée pour dépenser les fonds, on peut la demander et donc avertir le réseau de son utilisation, puis la déchiffrer avec la clé privée disponible sur le billet pour pouvoir dépenser les fonds.
D’ailleurs avec ça plus l’autocollant, on empêche de pouvoir facilement donner un billet déjà utilisé (autocollant déchiré) et de faire une copie (clé déjà demandée sur le réseau).
Edit : pas besoin de noter la clé publique B sur le billet.
ça ne change rien à ça à première vu, du coup, je ne suis pas sur que ça apporte concrètement plus de sécurité, alors que ça rajoute une complexité par le stockage réseau d’une clef privé (ou d’un fragment)
PS : avoir plusieurs clef publique sur le billet risque d’entrainer de la confusion et de nécessiter des QR-Code plus chargé et donc moins facile à scanner.
J’avoue que le qrcode façon puzzle me laisse dubitatif. N’importe qui prenant subrepticement une photo du dos du billet pourrait recoller les morceaux par logiciel (ça se fait vraiment en 2 minutes) et pomper le contenu du billet. Il faudrait au moins qu’un billet soit en fait en deux parties physiquement distinctes stockées à deux endroit différents. Du coup on tend le premier au destinataire, qui vérifie que le compte n’est pas vide, et lorsqu’il est rassuré, on lui donne le deuxième morceau. Ça limiterait au moins la possibilité de photographier tout d’un coup. Loin d’être parfait, mais un peu mieux. À voir.
J’ai édité mon post, il n’y a pas vraiment besoin de stocker la clé publique de chiffrement, il suffit au réseau de stocker l’association (clé publique fonds → clé privée chiffrée)
En cas de double demande par le client final et un “faussaire”, on pourrai ne prendre en compte que la dernière demande, ce qui ferai que le client final aurai une chance de ne pas se faire arnaquer, et même une envie certaine de déployer une certaine énergie à ne pas laisser l’arnaqueur, l’arnaquer.
Si le tricheur a fait une photo de la partie secrète du billet, il est tranquille, quelle que soit la sécurité numérique derrière.
Ta dernière solution, @Looarn, implique même que, si je reçoit un billet, tant que je n’ai pas les fonds le tricheur peut passer après moi et me bloquer (donc inquiétude prolongée)
Je suis pressé de voir ça !
