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).