From 5e6858a8217ca1d80dadcb02d68281ecaeff3b99 Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Mon, 18 Jan 2021 18:00:24 +0100 Subject: design doc for p2p payments --- design-documents/013-peer-to-peer-payments.rst | 130 +++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 design-documents/013-peer-to-peer-payments.rst 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). -- cgit v1.2.3