J’ouvre un nouveau fil pour répondre à cette objection.
Générer une TX, puis la donner au vendeur en hors-ligne, c’est équivalent, selon moi, à :
remplir un chèque (il faut les sources)
signer ce chèque (la signature de l’acheteur, via la pubkey/seckey), avec une date de signature
donner ce chèque pour dépot au vendeur, sans qu’il puisse encore vérifier sa validité
permettre au vendeur de déposer ce chèque (envoi de la TX sur la réseau)
En cas de fraude par l’acheteur (qui ferait une double dépense) : permette au vendeur de prouver que le chèque a bien signé, avec une date donné. Et donc de faire valoir son droit, à la justice de son pays, pour in-fine récupérer les fond.
Es-tu d’accord avec cela ?
Dis autrement, un chèque en bois est interdit, et reste interdit même si c’est ce chèque numérique. Autoriser les chèques reste néanmoins pratique et utile dans de nombreux cas. Si la confiance entre les deux acheteurs n’est pas suffisante, une pièce d’identité peut aussi être demandée.
Il s’agit en quelque sorte d’un contrat signé. Même hors ligne, ca reste un contrat qui engage celui qui le signe.
Il faut se garder de comparer avec l’existant des autres crypto-monnaies, avec lesquelles (à mon avis) ont n’est pas prêt d’aller acheter son pain de tous les jours…
Un autre cas d’usage auquel je penses :
l’acheteur est dans une boutique, mais capte mal le réseau (ca arrive souvent chez nous)
le vendeur, lui, à un terminal de paiement connecté à Internet.
l’acheteur émet sa TX depuis sont ordiphone, et le transmet au vendeur (via QR Code scanné ou en sans fil)
Aussitôt : le vendeur dépose la TX sur le réseau, qui est ainsi vérifié en terme de disponibilité de sources.
Dans ce cas de figure, seule le vendeur a Internet, mais la TX peut se faire, a condition que l’acheteur puissse avoir la liste de ses sources à jour. D’où ma demande de récupération des sources, de manière optimisée (delta)
it’s likely that a merchant is motivated to have access online (for themselves) if not their own node… so it enables them to take transactions safely from a client who just wants to get on with their day but is having a problem publishing their tx document.
it’s an argument FOR the blocknumber-blockhash in each tx document (useful fluff) to establish that the tx document was created sometime after this moment in time and signed/transmitted to receiver, leaving proof of what happened when (in the case that its a double-spend or is later double-spent).
it’s use might oblige further development:
wallets to store locally that sources have been included in offline-emitted transactions, or
wallets to provide user-control of source-selection, else how can user be held accountable?
No clue how nodes deal with multiple-source-spends coming into the mempool, but it seems useful to me that the oldest tx (by its blocknumber-blockhash stamp) might be valid and that later txs with same sources are invalid coming into the mempool (so they dont share this with other nodes and so they dont forge a block with an arguable double-spend). However, always the chance that some node never sees the valid tx and to invalidate an otherwise forged block because it includes a double-spend might fork a large portion of the network.
perhaps this feels useful but is in fact a great hazard… because it weakens our reliance on the sound blockchain idea of « If it hasn’t been confirmed by x-number of blocks… then it never happened. » (which is false, but also prudent)
Si deux vendeurs ont chacun reçu un chèque consommant la même source, lequel des deux pourra faire valoir son droit d’encaisser la source ? Avec n’importe quelle décision de justice, l’un des deux restera lésé, à part si on oblige l’arnaqueur à payer, ce qui est vachement compliqué.
On ne peut pas savoir quelle est la date de signature de la tx, mais uniquement à partir de quelle date elle a été signée. (rien ne m’empêche d’utiliser un blockstamp d’il y a très longtemps dans mes txs) Du coup je peux donner une tx datée d’un vieux bloc à un vendeur que j’aime bien et une tx datée plus récemment à un vendeur que je veux arnaquer. Ce dernier ne pourra donc pas “faire valoir son droit” si on se base sur les dates pour savoir laquelle est “légitime”.
Rien n’oblige le vendeur a accepter les chèques. C’est un risque qu’il assume, au regard de la confiance qu’il a dans l’acheteur. Par exemple, vendre sa voiture contre un chèque n’est pas recommandé. Pour autant, payer son employer avec un chèque est très courant, ou un amis, famille, etc. Ou même du pain, donc, au regard de la faible perte que cela engendre.
Du point de vue de la loi, l’acheteur doit payer les 2 vendeurs. Ca me parait simple.
I don’t think so. A block number is like time (with a 5 minutes precisions). The TX can refer to a past block, like a signed document can have a date in the past.
An alternative can be to a new field, in the TX document, to hold an approximate time.
The seller can then refused the payment, it the time seems to be incorrect.
C’est exactement ce que j’avais envie d’entendre ! On peut donner un moyen de paiement simple aux gens qui se font confiance à condition de bien en expliquer les limites. Et un jour on pourra implémenter les LN mais en attendant c’est quand même simple de faire une transaction à partir d’une liste de sources. Si en plus on notifie l’émetteur et le receveur que la condition de déblocage n’est pas satisfaite, ça leur donne l’occasion de s’organiser autrement.
De mon point de vue, le mieux serait que le chèque comporte 4 informations:
_La date de paiement (à la seconde prêt)
_Le montant
_La clé public du destinataire
_La signature de l’éméteur (générée à partir des 3 infos ci-dessus)
Ce chèque représenterait une promesse de paiement encaissable au bon vouloir du destinataire.
Le destinataire, pour créer l’encaissement devra y inscrire le chèque (donc toutes les infos de ce dernier) + la date d’encaissement + sa signature.
Le programme interdirait la possibilité qu’il y ai 2 chèques identiques. C’est à dire, même montant, même éméteur, même destinataire, même date (à la seconde prêt).
Aussi, le programme interdirait qu’il y ai 2 encaissements portant sur un même chèque.
Du coup, pour l’acheteur, il n’y aurait pas besoin de connexion internet pour générer le chèque.
Pour le vendeur, il n’y aurait pas besoin de connexion internet pour vérifier la cohérence du chèque.
Une connexion internet en revanche serait nécessaire pour vérifier que le compte est bien approvisionné. Si le compte n’est pas approvisionné, le chèque lui permettrait de récupérer son dû plus tard si un jour le compte est approvisionné.
Une connexion internet serait donc quand même recommandé par le vendeur car le compte de l’acheteur pourrait être un compte secondaire sur lequel il n’y a jamais de monnaie par exemple.
Attention la métaphore du chèque n’est pas exacte!
Un chèque c’est « demander à la banque de payer au destinataire »
En monnaie libre il n’y a pas de banque. Je dirais que en hors ligne le payeur s’engage à payer, s’il ne paie pas, il n’y a pas vraiment de recours possible.
Le chèque n’était qu’une Image, pour parler d’une TX. Pas besoin de réinventer la roue : une transaction avec des sources comporte tout ce qu’il faut. Autant exploiter a fond ce dont on dispose dans le protocole, plutôt de vouloir développer un autre truc, hors protocole.
Le G1PASS de Fred m’a fait penser de nouveau à cette idée, pour Duniter V2S.
Une sorte de chèque QRCode à donner au vendeur, avec extrinsic signé du montant désiré. Tikka ou n’importe quel client qui supporterait cette fonctionnalité pourrait générer une transaction signée en QRcode et en importer via webcam pour l’exécuter.
Avec toujours l’analogie du chèque qui peut être en bois.
En tout cas c’est assez trivial à coder, je le garde en tête pour Tikka.
Les oneshot accounts sont plus ou moins faits pour ça. On peut imprimer soit les clés du compte soit un extrinsic qui vide le compte vers un compte donné.
On ne peut pas faire ça avec un compte normal, car les extrinsics requièrent un nonce. (tout extrinsic émis avant encaissement du chèque pourrait annuler le chèque)
