[taler-docs] branch master updated: design doc for p2p payments

[gnunet]

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

dold pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 5e6858a  design doc for p2p payments
5e6858a is described below

commit 5e6858a8217ca1d80dadcb02d68281ecaeff3b99
Author: Florian Dold <florian@dold.me>
AuthorDate: Mon Jan 18 18:00:24 2021 +0100

    design doc for p2p payments
---
 design-documents/013-peer-to-peer-payments.rst | 130 +++++++++++++++++++++++++
 1 file changed, 130 insertions(+)

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 0000000..c5e529d
--- /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).

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