summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--design-documents/013-peer-to-peer-payments.rst130
1 files changed, 130 insertions, 0 deletions
diff --git a/design-documents/013-peer-to-peer-payments.rst b/design-documents/013-peer-to-peer-payments.rst
new file mode 100644
index 00000000..c5e529d6
--- /dev/null
+++ b/design-documents/013-peer-to-peer-payments.rst
@@ -0,0 +1,130 @@
+Design Doc 013: Customer-to-Customer Payments
+#############################################
+
+Summary
+=======
+
+This design document proposes an extension of the Taler protocol that allows
+payments from customer-to-customer without a merchant.
+
+Motivation
+==========
+
+To be usable as an electronic payment system with cash-like properties,
+customers should be able to transfer money between themselves without any
+external provider.
+
+
+Requirements
+============
+
+* 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
+ party beyond the point where the money has been received by the payee. Thus,
+ sharing of coin private keys is not sufficient.
+* The P2P payment protocol must not allow users to circumvent income
+ transparency. That is, each P2P 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.
+
+Proposed Solution
+=================
+
+A complete solution for customer-to-customer payments consists of three
+separate parts:
+
+1. The mechanism whereby coins are deposited into some address
+ associated with the receiver.
+2. A mechanism to ensure that the receiver of a customer-to-customer
+ payment must have undergone a KYC check.
+3. If more than once exchange should be supported, there must be a real-time
+ settlement layer between involved exchanges.
+
+
+Customer-to-customer Deposits
+-----------------------------
+
+The payer deposits coins (via the existing /deposit protocol) into a
+``payto://taler-p2p-pouch/$POUCH_PUB`` address. The exchange handles this
+deposit by internally transfering the money to a "pouch" identified by the
+pouch public key (``$POUCH_PUB``).
+
+Once a pouch has been funded, the payer can additionally attach some meta-data
+(e.g. remittance information) to the pouch.
+
+The payee claims the payment by transfering funds from the (anonymous) pouch
+into a KYCed reserve (also called a "bound reserve", as it is bound to
+personally identifying information of the owner") that belongs to the payee.
+
+Alternatively the payee can also choose to receive the funds on their bank
+account, simply by providing their bank account (as a payto URI) in the pouch
+claiming request.
+
+The exchange needs a new endpoint for this:
+
+::
+
+ POST {exchangeBaseUrl}/pouches/$POUCH_PUB/claim
+ Request:
+ {
+ bound_reserve_exchange: "..."
+ bound_reserve_pub: "..."
+ }
+ Response:
+ {
+ amount: "...",
+ }
+
+Note that the bound reserve might exist at a different exchange.
+
+Bound Reserves
+--------------
+
+A bound reserve is a reserve that is associated with personally identifyable
+information of the customer.
+
+A bound reserve is created by depositing small cover fee into it and then going
+through an exchange-specific KYC process. If an exchange is operated by a bank
+that a customer already has a business relationship with, the bank might
+automatically provide a bound reserve for that customer.
+
+To prevent abuse of bound reserves (in the form of multiple parties exchanging
+funds via shared access to a bound reserve), the following measures can be
+taken:
+
+* Creation of additional bound reserves per customer can
+ be discouraged by asking for higher fees.
+* The global transaction volume of one customer can be easily
+ determined by authorities, which can then trigger further audits
+ of the customer
+* As a technically expensive but more water-tight measure, normal
+ withdrawals from bound reserves could be disallowed. Instead,
+ a modified refresh protocol could ensure that whoever has knowledge
+ of the reserve private key can also learn the private keys
+ of coins withdrawn from that reserve.
+
+Bound reserves could also be used to remove Taler's "one-hop withdrawal
+loohole".
+
+Alternatives
+============
+
+* The payer could directly give deposit permissions to the payee.
+ This has two problems:
+
+ 1. The payer doesn't know the wire details of the payee.
+ Thus we would need to introduce some "wildcard deposit permission",
+ where the exchange allows any wire details on ``/deposit``.
+ 2. The payment information would be rather large, making it difficult
+ to transfer via a QR code or short text message.
+
+
+Drawbacks
+=========
+
+* The exchange needs to be extended with customer-to-customer pouches (probably
+ the easy part) and bound reserves (possibly falls into the responsibility of
+ LibEuFin).