Le ChéĞuier
Suite à la proposition de @1000i100 de développer un système de billet “offline”, on a réfléchi sur la route du retour des RML11 avec @kimamila à un autre système, qui s’appuierait sur des chéquiers.
On est d’abord parti du “pourquoi a-t-on besoin d’un tel système” ? :
- possibilité de payer “offline”
- paiement fluide qui ne nécessite pas d’attendre que la chaine valide les transactions
Pour ce faire, on s’appuie sur un chéquier, imprimé par un membre de la toile de confiance, et une base centralisée de gestion des litiges. Le chéquier des RML11 a été une grande source d’inspiration du système.
Format du chèque
- chéquier en 3 parties : un talon et deux segments détachables
Description :
-
Talon : à remplir comme un chèque classique
-
Segment gauche : “Ce que je dois”
- un QRcode généré (à la création du chéquier) qui contient : la condition XHX aléatoire + le commentaire de référence du chèque (blockstamp d’émission + numéro du chèque)
- Puis les infos à remplir : montant, date et les deux signatures
- Les signatures manuscrites peuvent être une option permettant à l’émetteur et au receveur de déclarer qu’ils s’engagent tout les deux à résoudre cette transaction
-
Segment droite : “ce que je donne” :
- un QRcode généré qui contient le code de la condition XHX ET le commentaire de référence du chèque;
- Puis les infos à remplir : montant, date et les deux signatures
Notes :
- les deux QRcode sont signés par l’émetteur du chèque (qui doit être un compte membre).
- possibilité d’imprimer le chéquier en recto verso avec une partie du code sur le verso (comme sur les CB avec le code de vérification au dos)
Processus d’utilisation
- Chacun peut imprimer son propre chéquier, qui sera signé par notre clé publique (via les QRCode) ;
- Pour payer : l’acheteur donne un chèque (segment de droite) et s’engage à verrouiller le montant en blockchain dès qu’il pourra (=recouvrement).
- Le vendeur qui reçoit le chèque, pourra l’encaisser en le déverrouillant à tout moment (= dépôt du chèque).
- Une application permet :
- de générer des transactions avec un commentaire qui indiquera que le chèque est révoqué (en cas de vol par exemple = opposition) - ces TX peuvent être pré-imprimé en même temps que le chéquier, ou bien regénéré à partir du simple numéro du chéquier;
- une base de données est disponible pour déclarer les chèques impayés. Ceci permet aussi de ne pas accepter les chèques des fraudeurs ou de non payeur. La déclaration s’appuie sur la blockchain (tel chèque avec tel code n’a pas été enregistré dans la chaine, la preuve)
- comme un chèque ne peut être émis que par un membre, des fraudeurs réguliers sont identifiable, pourraient être référencés et bloqués à l’avenir;
Fonctions potentielles
- un chéquier signé par du multi-tenants. Un fond de garantie peut s’engager pour celui qui fait le chèque, permettant de déléguer la confiance à un tiers, qui s’engage au recouvrement en cas d’impayé. Possibilité de mettre deux verrous sur les TX (un verrou connu par chaque parti).
- Si l’émetteur du chèque ne paie pas, le fond de garantie peut payer à sa place;
Limites
En cas de transfert de la monnaie sur une clé publique qui n’est pas celle attendue, comment prouver qui est à l’origine du problème ? Les deux partis (envoyeur et receveur) doivent alors être enregistrés sur la base des litiges de chéquier.
C’est de l’online asynchrone avec promesse offline de paiement on va dire 