[taler-docs] branch master updated: extended requirement list

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 64c9416  extended requirement list
     new 3efd020  Merge branch 'master' of git+ssh://git.taler.net/docs
64c9416 is described below

commit 64c941695820f7cc9d89162a3adac1f5bf16d5bf
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Fri Apr 16 12:07:38 2021 +0200

    extended requirement list
---
 design-documents/013-peer-to-peer-payments.rst | 38 +++++++++++++++++++++-----
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/design-documents/013-peer-to-peer-payments.rst 
b/design-documents/013-peer-to-peer-payments.rst
index 64fe8a7..3e60859 100644
--- a/design-documents/013-peer-to-peer-payments.rst
+++ b/design-documents/013-peer-to-peer-payments.rst
@@ -18,18 +18,42 @@ needing to setup anything beyond their wallet(s).
 Requirements
 ============
 
+* The protocol must permit transacting arbitrary amounts in any currency,
+  as long as both parties trust the exchange involved.
 * The control data for customer-to-customer payments should be small
-  enough to fit into a QR code or short message.  No other
-  direct communication channel between payer and payee should be required.
-* This customer-to-customer payment must be possible without trusting the other
+  enough to fit into a QR code or short message (so ideally less than 64 
bytes).
+* No other direct communication channel between payer and payee should
+  be required.
+* The customer-to-customer payment must be possible without trusting the other
   party beyond the point where the money has been received by the payee.  Thus,
   sharing of coin private keys is not sufficient, we need transactional 
semantics
   resulting in exclusive control over the funds by the recipient.
-* The P2P payment protocol must not allow users to circumvent income
-  transparency.  That is, each P2P transaction must be visible
+* The customer-to-customer payment protocol must not allow users to circumvent 
income
+  transparency.  That is, each customer-to-customer transaction must be visible
   on a KYCed transaction ledger (such as a bank account).
-* The money received via a P2P payment must be usable for
-  further Taler payments with minimal delay.
+* The money received via a customer-to-customer payment must be usable for
+  further Taler payments with minimal delay (after KYC).
+* Two payment scenarios must be possible: (1) one where the payee first
+  transmits a proposal to the payer (request-to-pay) that the payer
+  accepts by making the payment, and (2) completely uni-directional
+  payments where the payer includes a proposal with the payment and the
+  payee accepts the proposal by taking the offered payment.
+* If the payment fails (i.e. the receiver refuses to accept the money
+  or the message is lost), the payer must automatically recover the
+  funds (minus applicable fees) without the need for further communication.
+* If funds flow back to the payer due to an aborted payment, it must be
+  provable for the payer that these funds were not income but merely an aborted
+  transaction.  Furthermore, in this case, no KYC should be required from the
+  payer.
+* If a payment would partially succeed, i.e. because the payer inadvertedly
+  used some double-spent coins and some valid coins, this must fail before the
+  uni-directional communication and be correctable payer-side.
+* The usual properties of Taler (everything auditable, high-performance
+  in terms of CPU, bandwidth, latency, storage requirements, and the
+  ability to levy fees on every operation that is costly for the exchange)
+  need to be preserved.
+
+
 
 New Terminology
 ===============

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.