extended requirement list

1 files 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 64fe8a7f..3e608597 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
 ===============