summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2021-04-16 12:07:38 +0200
committerChristian Grothoff <christian@grothoff.org>2021-04-16 12:07:38 +0200
commit64c941695820f7cc9d89162a3adac1f5bf16d5bf (patch)
tree97f5f6420b661232cf93e080289d21f1e4bddb76
parent24db2e8e24c1b089352b91730bb6bc378b3e6638 (diff)
downloaddocs-64c941695820f7cc9d89162a3adac1f5bf16d5bf.tar.gz
docs-64c941695820f7cc9d89162a3adac1f5bf16d5bf.tar.bz2
docs-64c941695820f7cc9d89162a3adac1f5bf16d5bf.zip
extended requirement list
-rw-r--r--design-documents/013-peer-to-peer-payments.rst38
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 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
===============