ngi-pointer-ap3/m4/p2p-report.tex

%\documentclass{article}
\documentclass[a4paper,12pt]{article}
\usepackage[english]{babel}
%\usepackage[a4paper,top=20mm,bottom=20mm,left=20mm,right=20mm,marginparwidth=1.75cm]{geometry}
\usepackage[a4paper,top=20mm,bottom=20mm,left=20mm,right=20mm]{geometry}
\usepackage{array}
\usepackage[framemethod=tikz]{mdframed}
\usepackage{makecell}
\usepackage{enumitem}
\usepackage{xcolor}
\usepackage{parskip}

\newcolumntype{P}[1]{>{\centering\arraybackslash}p{#1}}
\newcolumntype{M}[1]{>{\centering\arraybackslash}m{#1}}

\newenvironment{changemargin}[2]{%
\begin{list}{}{%
\setlength{\topsep}{0pt}%
\setlength{\leftmargin}{#1}%
\setlength{\rightmargin}{#2}%
\setlength{\listparindent}{\parindent}%
\setlength{\itemindent}{\parindent}%
\setlength{\parsep}{\parskip}%
}%
\item[]}{\end{list}}

% Useful packages
\usepackage{amsmath}
\usepackage{graphicx}
\usepackage[colorlinks=true, allcolors=blue]{hyperref}

%\title{Your Paper}
%\author{You}
\begin{document}
%\maketitle

%\begin{abstract}
%Your abstract.
%\end{abstract}

\begin{center}
{\Huge \textsc{NGI POINTER: Peer-to-Peer Payments}}
\end{center}

\section{Context}

For the NGI POINTER programme, the GNU Taler team developed
age-restricted payments, peer-to-peer (P2P) payments and a proof-of-concept
ability to extend GNU Taler with escrow functionality for
privacy-preserving auctions.  This document provides some
details on the state of the P2P payment functionality.

\section{Overview}

We implemented two styles of P2P payments: {\bf push payments} where a
user sends money to another Taler wallet (which can then accept the
payment), and {\bf pull payments} where a user sends an invoice to
another Taler wallet (which can then pay the invoice).

Both styles of payment only require one asynchronous uni-directional
secure communication between the wallets to make the payment. The
information that is exchanged is in both cases a short {\tt
  taler://}-URI which allows the wallet to obtain further details from
the payment service provider. These further details include the
contract/invoice that the payment is for. The contract/invoice is
stored encrypted at the exchange and thus cannot be learned by the
exchange.

The actual P2P payment works by having the initiator wallet first
communicate with the Taler exchange to setup the payment. Then the
Taler URI is communicated to the other wallet, for now usually via
QR code or NFC transmission; however, users could also copy the URI
to the clipboard and exchange it via some (secure) messenger. Upon
receiving the URI, the other wallet then again interacts with the
exchange to obtain more details and complete the payment.

If the recipient of a push payment does not accept the payment
(say because the message was lost in transmission, or they do not
like the attached contract terms) the money is automatically refunded
to the payer after some expiration date is reached.

\section{Technical details}

P2P payments always work by establishing a {\bf purse} at the
exchange.  A purse has an expiration date, target amount, minimum age,
associated business contract (or invoice), an actual balance and two
public-private key pairs representing permissions to operate on the
purse.  For a push payment, the wallet of the sending user creates a
purse (with contract and expiration time) and immediately ensures that
the balance of the purse is the target amount.  The payer then sends
the merge-capability key of the purse to the payee.  The payee can
then use the merge-capability key to merge (move) the balance of the
purse into a KYCed reserve of the receiving wallet.  A KYCed reserve
basically is a long-term public-private key pair that identifies a
wallet and a user at an exchange, ensuring income transparency. Once
the money is in the reserve, the wallet can then use the reserve
private key to withdraw fresh coins.

When invoicing, the initiator again creates a purse, but this time
does not put any money into it and keeps the merge capability key
private.  The initiator wallet instead immediately specifies its own
KYCed reserve as the one the purse should be merged into.  The
initiator then shares a contract-download capability key with the
payer.  The payer downloads the contract (including the purse public
key) and can then decide to put money into the purse. Once the purse
balance reaches the target amount, it is then automatically merged
with the initiator's reserve. The initiator's wallet (long) polls the
reserve and withdraws the funds as soon as they become available.

The protocol and implementation includes a few refinements, like fees
to be paid to the exchange for managing a purse and age-restrictions
on the coins used to pay an invoice.

\section{Future Work}

The following features (from tiny to major) have been discussed in
the team and ought to be implemented as part of future work.

\begin{itemize}
\item {\bf Wallets:} The wallet UIs currently do not allow the user to actually specify
  any age-restrictions on the payer when sending P2P pull payment requests
  (invoicing).  This mostly is about adding one more drop-down widget.
\item {\bf Wallets:} The wallet UIs currently do not allow the user to actually specify
  the expiration date for the purse. Instead, the duration is hard-coded
  to a few hours (likely too short). This mostly is about adding one more
  input field.
\item {\bf Auditor:} The Taler auditor was extended to support P2P transactions in
  its audits, but the code has not been adequately tested (no
  fault injection).
\item {\bf Exchange:} P2P payments currently only work if both wallets are using the
  same exchange.  If multiple exchanges operate in the same currency
  domain and the recipient has made their (expensive) KYC process
  at one exchange and the payer has withdrawn from the other, a
  direct payment between the wallets is not possible right now.  We
  envision federation protocol using periodic aggregated
  (``wad'') payments between exchanges should be added to support
  P2P payments involing multiple exchanges in the future.
\item {\bf Mailbox (NEW):} Currently, sending the payment URI is largely left to the user.
  We would like to implement a ``mailbox'' service for Taler wallets
  that would enable wallets to asynchronously exchange URIs over the
  Internet.  Once a wallet knows the mailbox address of another wallet
  (which would include a public key to encrypt messages to), the user
  would no longer be required to manually exchange the QR code.
\item {\bf TalDir (NEW):} To lookup the mailbox address of another wallet, we would like
  to implement a directory service that maps existing addresses like
  e-mail addresses, phone numbers or accounts in messengers or social
  media platforms to a mailbox. When establishing the directory service
  entry, the directory service would validate that the user registering
  the wallet has control over the respective address.  Naturally, the
  directory service would need to be trusted to return the correct
  mapping.
\item Both the mailbox and the directory service operators could
  themselves be paid via Taler for their service. That should help
  ensure a high quality of service from those operators.  Naturally,
  using the mailbox or the directory service would be optional.
\item {\bf Messaging:} In the long term, we would like to see more direct integration
  of Taler payment functionality with messaging applications, especially
  for spam prevention (``The recipient has configured its software to
  demand a payment of 50 cents before displaying a message from an unknown
  sender to the user. If they like your message, they promise they would
  refund this attention fee. Do you want to pay to have your message
  shown? (Y/N)'').
\end{itemize}


\section{Links}

The design is documented at
\url{https://docs.taler.net/design-documents/013-peer-to-peer-payments.html}.

The main implementation parts are distributed over various
code locations:

\begin{description}
  \item[Peer-to-peer payment operations in wallet:] \url{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/operations/pay-peer.ts}
  \item[Database schema with p2p state in it:] \url{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/db.ts#n2065}
  \item[Peer-to-peer transactions in the transaction list type declarations:] \url{https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/transactions-types.ts#n251}
  \item[WebExtension UI stuff related to peer-to-peer:] \url{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-webextension/src/cta/InvoiceCreate}, \url{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-webextension/src/cta/InvoicePay}
  \item[Exchange] \url{https://git.taler.net/exchange.git/tree/src/exchange/},
    specifically {\tt taler-exchange-httpd\_purses\_*.c}, {\tt taler-exchange-httpd\_reserves\_purse\_*.c},
    {\tt taler-exchange-httpd\_contract.*},
    {\tt taler-exchange-expire.c} (plus related changes in the database, client libraries, history, auditor),
    and the main test case at {\tt https://git.taler.net/exchange.git/tree/src/testing/test\_exchange\_p2p.c}
\end{description}



\end{document}