Paiements offlines - Le ChéĞuier


#1

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

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.


#2

Je ne comprend pas pourquoi il y aurais besoin de la signature du receveur ?

Ni l’intérêt du talon si le payeur garde de toute façon la partie de gauche.

PS : pour l’handicapé de l’écriture manuscrite que je suis, le chéǦuier répond partiellement au besoin d’offline mais pas du tout à l’objectif fluidité. (mais tout le monde n’est pas handicapé de l’écriture manuscrite)

Pourquoi je dis “partiellement” ?
Parce-que chaque utilisateur du chéǦuier doit quand même à un moment aller online pour effectuer sa transaction.


#3

Tout à fait :slight_smile: C’est de l’online asynchrone avec promesse offline de paiement on va dire :wink:

Potentiellement, à cause du problème du transfert de monnaie sur une clé publique, je dirais.

Alors dans mon idée, la partie gauche était “jetée” une fois consommée (pour pas s’embrouiller) tandis que le talon fait office d’historique sur l’usage du chéquier.

Bon ceci dit, je ne me sers jamais du talon de mon chéquier UNL… :slight_smile:

On peut je pense envisager des imprimantes qui pré-remplissent chaque champs (comme dans les supermarchés).


#4

C’est de l’émission de crédit en fait la partie de droite, remboursé au moment du paiement effectif (partie de gauche consommée). N.B. : je n’ai pas de problème avec ça, tant que la monnaie derrière est libre.

Par contre vu que le montant est libre, le litige s’il y en a un ne peut pas être tranché. C’est la parole de l’un face à la parole de l’autre, et la signature manuelle n’a pas grande valeur.


#5

Pour supprimer la limite du “que se passe-t-il si le receveur de la monnaie est une clé publique quelconque”, il faudrait un verrou supplémentaire du type MEMBER_SIG qui dit qu’en gros, celui qui peut déverouiller la monnaie est une clé publique parmis les membres.

Le verrou deviendrait alors XHX( ) && MEMBER_SIG. La monnaie ne peut alors que être déverrouillée par la signature d’une clé membre. La phase de recouvrement/dépot de chèque est donc protégée contre un litige de ce type.

C’est en effet la signature manuelle qui permet en théorie de conclure sur la parole de l’un face à la parole de l’autre.

Pour le problème du montant libre, c’est effectivement un cas de litige subtile. La double signature manuelle est effectivement une faible protection, mais une protection quand même. A voir si d’autres sont inspirés :slight_smile:


#6

Et dire que la MNL a longtemps fonctionné et fonctionne encore comme ça…
Que dire des maquignons qui topaient dans la main à la foire aux bestiaux ?

Toute transaction en dehors de l’écriture dans la blockchain reposera inévitablement sur la confiance entre les protagonistes ou entre le vendeur et un organisme (Ğanque de dépot) de confiance.


#7

Je ne veux pas dire “dans l’absolu”, mais par rapport et à la blockchain Ğ1 et à l’entité centralisée censée gérer les litiges, d’un point de vue technique.

Comme tu le sais les contrats écrits ne servent à rien, sauf en cas de litige auquel cas le contrat doit être explicite et faire référence à des éléments de droit qui peuvent être clamés devant un tribunal.

Là, je vois pas trop auprès de qui défendre quoi, ni donc qui peut trancher quoi.