path: root/doc/paper/taler.tex

% RMS wrote:
%The text does not mention GNU anywhere.  This paper is an opportunity
%to make people aware of GNU, but the current text fails to use the
%opportunity.
%
%It should say that Taler is a GNU package.
%
%I suggest using the term "GNU Taler" in the title, once in the
%abstract, and the first time the name is mentioned in the body text.
%In the body text, it can have a footnote with more information
%including a reference to http://gnu.org/gnu/the-gnu-project.html.
%
%At the top of page 3, where it says "a free software implementation",
%it should add "(free as in freedom)", with a reference to
%http://gnu.org/philosophy/free-sw.html and
%http://gnu.org/philosophy/free-software-even-more-important.html.
%
%Would you please include these things in every article or posting?
%
% CG adds:
% We SHOULD do this for the FINAL paper, not for the anon submission.

\documentclass{llncs}
%\usepackage[margin=1in,a4paper]{geometry}
\usepackage[T1]{fontenc}
\usepackage{palatino}
\usepackage{xspace}
\usepackage{microtype}
\usepackage{tikz,eurosym}
\usepackage{amsmath,amssymb}
\usepackage{enumitem}
\usetikzlibrary{shapes,arrows}
\usetikzlibrary{positioning}
\usetikzlibrary{calc}
\usepackage{caption}
\usepackage{subcaption}
\usepackage{subfig}

% Relate to:
% http://fc14.ifca.ai/papers/fc14_submission_124.pdf

% Terminology:
% - SEPA-transfer -- avoid 'SEPA transaction' as we use
%       'transaction' already when we talk about taxable
%        transfers of Taler coins and database 'transactions'.
% - wallet = coins at customer
% - reserve = currency entrusted to exchange waiting for withdrawal
% - deposit = SEPA to exchange
% - withdrawal = exchange to customer
% - spending = customer to merchant
% - redeeming = merchant to exchange (and then exchange SEPA to merchant)
% - refreshing = customer-exchange-customer
% - dirty coin = coin with exposed public key
% - fresh coin = coin that was refreshed or is new
% - denomination key = exchange's online key used to (blindly) sign coin
% - message signing key = exchange's online key to sign exchange messages
% - exchange master key = exchange's key used to sign other exchange keys
% - owner = entity that knows coin private key
% - transaction = coin ownership transfer that should be taxed
% - sharing = coin copying that should not be taxed


\title{Taler: Taxable Anonymous Libre Electronic Reserves}

\begin{document}
\mainmatter

%\author{Florian Dold \and Sree Harsha Totakura \and Benedikt M\"uller \and Jeff Burdges \and Christian Grothoff}
%\institute{The GNUnet Project}


\maketitle

\begin{abstract}
This paper introduces Taler, a Chaum-style digital currency that
enables anonymous payments while ensuring that entities that receive
payments are auditable and thus taxable.  In Taler, customers can
never defraud anyone, merchants can only fail to deliver the
merchandise to the customer, and payment service providers can be
fully audited.  All parties receive cryptographic evidence for all
transactions; still, each party only receives the minimum information
required to execute transactions.  Enforcement of honest behavior is
timely, and is at least as strict as with legacy credit card payment
systems that do not provide for privacy.  Taler allows fractional
payments while maintaining unlinkability of transactions.  We argue
that Taler provides a secure digital currency for modern liberal
societies as it is a flexible, libre and efficient protocol and
adequately balances the state's need for monetary control with the
citizen's needs for private economic activity.
\end{abstract}

\section{Introduction}

The design of payment systems shapes economies and societies.  Strong,
developed nation states are evolving towards transparent payment
systems, such as the MasterCard and VisaCard credit card schemes and
computerized bank transactions such as SWIFT.  These systems enable
mass surveillance by both governments and private companies.  Aspects
of this government control benefit the economy, by enabling taxation
(also called anti-money laundering).  As a result, bribery and
corruption are limited to elites who can afford to escape the dragnet.
At the other extreme, weaker developing nation states have economic
activity based largely on coins, paper money or even barter.  Here,
the state is often unable to effectively monitor or tax economic
activity, and this limits the ability of the state to shape the
society.  As bribery is virtually impossible to detect, corruption is
widespread and not limited to social elites.
%
ZeroCoin~\cite{miers2013zerocoin} is an example for translating an
anarchistic economy into the digital realm.
% FIXME: Unclear referee comment :
% I didn’t understand why ZeroCoin is particularly suited for
% developing nations?
% => clarified: suited to model anarchistic economy.

This paper describes Taler, a simple and practical payment system for
a modern social-liberal society, which is not being served well by
current payment systems which enable either an authoritarian state in
total control of the population, or create weak states with almost
anarchistic economies.

The Taler protocol is influenced by ideas from
Chaum~\cite{chaum1983blind} and also follows Chaum's basic architecture of
customer, merchant and exchange (Figure~\ref{fig:cmm}).
The two designs share the key first step where the {\em customer}
withdraws digital {\em coins} from the {\em exchange} with unlinkability
provided via blind signatures.  The coins can then be spent at a
{\em merchant} who {\em deposits} them at the exchange.
Taler uses online detection of double-spending, thus assuring the merchant
instantly that a transaction is valid.

\begin{figure}[h]
\centering
\begin{tikzpicture}
 \tikzstyle{def} = [node distance= 1em and 11em, inner sep=1em, outer sep=.3em];
 \node (origin) at (0,0) {};
 \node (exchange) [def,above=of origin,draw]{Exchange};
 \node (customer) [def, draw, below left=of origin] {Customer};
 \node (merchant) [def, draw, below right=of origin] {Merchant};
 \node (auditor) [def, draw, above right=of origin]{Auditor};

 \tikzstyle{C} = [color=black, line width=1pt]

 \draw [<-, C] (customer) -- (exchange) node [midway, above, sloped] (TextNode) {withdraw coins};
 \draw [<-, C] (exchange) -- (merchant) node [midway, above, sloped] (TextNode) {deposit coins};
 \draw [<-, C] (merchant) -- (customer) node [midway, above, sloped] (TextNode) {spend coins};
 \draw [<-, C] (exchange) -- (auditor) node [midway, above, sloped] (TextNode) {verify};

\end{tikzpicture}
\caption{Taler's system model for the payment system is based on Chaum~\cite{chaum1983blind}.}
\label{fig:cmm}
\end{figure}


A key issue for an efficient Chaumian digital payment system is the
need to provide change.  For example, a customer may want to pay
\EUR{49,99}, but has withdrawn a \EUR{100,00} coin.  Withdrawng 10,000
pieces with a denomination of \EUR{0,01} and transferring 4,999 would
be too inefficient, even for modern systems.  The customer should not
withdraw exact change from her account, as doing so reduces anonymity
due to the obvious corrolation.  A practical payment system must thus
support giving change in the form of spendable coins, say a \EUR{0,01}
coin and a \EUR{50,00} coin.

Taler solves the problem of giving change by introducing a new {\em
  refresh} protocol.  Using this protocol, a customer can obtain
change in the form of fresh coins that other parties cannot link to
the original transaction, the original coin, or each other.
Additionally, the refresh protocol ensures that the change is owned by
the same entity which owned the original coin.


\section{Related Work}

\subsection{Blockchain-based currencies}

In recent years, a class of decentralized electronic payment systems,
based on collectively recorded and verified append-only public
ledgers, have gained immense popularity.  The most well-known protocol
in this class is Bitcoin~\cite{nakamoto2008bitcoin}.  An initial
concern with Bitcoin was the lack of anonymity, as all Bitcoin
transactions are recorded for eternity, which can enable
identification of users.  In theory, this concern has been addressed
with the Zerocoin extension to the protocol~\cite{miers2013zerocoin}.

These protocols dispense with the need for a central, trusted
authority, while providing a useful measure of pseudonymity.
Yet, there are several major irredeemable problems inherent in their designs:

\begin{itemize}
  \item The computational puzzles solved by Bitcoin nodes with the purpose
    of securing the block chain consume a considerable amount of energy.
    So Bitcoin is an environmentally irresponsible design.
  \item Bitcoin transactions have pseduononymous recipients, making taxation
    hard to systematically enforce.
    The Zerocoin extension makes this worse.
  \item Bitcoin introduces a new currency, creating additional
    financial risks from currency fluctuation.
  \item Anyone can start an alternative Bitcoin transaction chain,
    called an AltCoin, and, if successful, reap the benefits of the low
    cost to initially create coins cheaply as the proof-of-work
    difficulty adjusts to the computation power of all
    miners in the network.  As participants are
    de facto investors, AltCoins become a form of ponzi scheme.
    % As a result, dozens of
    % AltCoins have been created, often without any significant changes to the
    % technology.  A large number of AltCoins creates additional overheads for
    % currency exchange and exacerbates the problems with currency fluctuations.
\end{itemize}

%GreenCoinX\footnote{\url{https://www.greencoinx.com/}} is a more
%recent AltCoin where the company promises to identify the owner of
%each coin via e-mail addresses and phone numbers.  While it is unclear
%from their technical description how this identification would be
%enforced against a determined adversary, the resulting payment system
%would also merely impose a financial panopticon on a BitCoin-style
%money supply and transaction model.

\subsection{Chaum-style electronic cash}

Chaum~\cite{chaum1983blind} proposed a digital payment system that
would provide some customer anonymity while disclosing the identity of
the merchants.  DigiCash, a commercial implementation of Chaum's
proposal, had some limitations and ultimately failed to be widely
adopted.  In our assessment, key reasons for DigiCash's failure
include:

\begin{itemize}
 \item The use of patents to protect the technology; a payment system
   should be free software (libre) to have a chance for widespread adoption.
 \item Support for payments to off-line merchants, and thus deferred
   detection of double-spending, requires the exchange to attempt to
   recover funds from delinquent customers via the legal system.
   Any system that fails to be self-enforcing creates a major
   business risk for the exchange and merchants.
%   In 1983, there were merchants without network connectivity, making that
%   feature relevant, but today network connectivity is feasible for most
%   merchants, and saves both the exchange and merchants the business risks
%   associated with deferred fraud detection.
 \item % In addition to the risk of legal disputes with fraudulent
   % merchants and customers,
   Chaum's published design does not clearly
   limit the financial damage a exchange might suffer from the
   disclosure of its private online signing key.
 \item Chaum did not support fractional payments or refunds without
   weakening customer anonymity.
%, and Brand's
%   extensions for fractional payments broke unlinkability and thus
%   limited anonymity.
% \item Chaum's system was implemented at a time where the US market
%   was still dominated by paper checks and the European market was
%   fragmented into dozens of currencies.  Today, SEPA provides a
%   unified currency and currency transfer method for most of Europe,
%   significantly lowering the barrier to entry into this domain for
%   a larger market.
\end{itemize}

Chaum's original digital cash system~\cite{chaum1983blind} was
extended by Brands~\cite{brands1993efficient} with the ability to {\em
  divide} coins and thus spend certain fractions of a coin using
restrictive blind signatures.  Restrictive blind signatures create
privacy risks: if a transaction is interrupted, then any coins sent to
the merchant become tainted, but may never arrive or be spent.  It
becomes tricky to extract the value of the tainted coins without
linking to the aborted transaction and risking deanonymization.

Ian Goldberg's HINDE system allowed the merchant to provide change,
but the mechanism could be abused to hide income from
taxation.\footnote{Description based on personal communication. HINDE
  was never published.}  $k$-show
signatures~\cite{brands1993efficient} were proposed to achieve
divisibility for coins.  However, with $k$-show signatures multiple
transactions can be linked to each other.  Performing fractional
payments using $k$-show signatures is also rather expensive.

%
%Some argue that the focus on technically perfect but overwhelmingly
%complex protocols, as well as the the lack of usable, practical
%solutions lead to an abandonment of these ideas by
%practitioners~\cite{selby2004analyzing}.
%

% FIXME: ask OpenCoin dev's about this! Then make statement firmer!
To our knowledge, the only publicly available effort to implement
Chaum's idea is Opencoin~\cite{dent2008extensions}.  However, Opencoin
is neither actively developed nor used, and it is not clear
to what degree the implementation is even complete.  Only a partial
description of the Opencoin protocol is available to date.


%\subsection{Peppercoin}

%Peppercoin~\cite{rivest2004peppercoin} is a microdonation protocol.
%The main idea of the protocol is to reduce transaction costs by
%minimizing the number of transactions that are processed directly by
%the exchange.  Instead of always paying, the customer ``gambles'' with the
%merchant for each microdonation.  Only if the merchant wins, the
%microdonation is upgraded to a macropayment to be deposited at the
%exchange.  Peppercoin does not provide customer-anonymity.  The proposed
%statistical method by which exchanges detect fraudulent cooperation between
%customers and merchants at the expense of the exchange not only creates
%legal risks for the exchange, but would also require that the exchange learns
%about microdonations where the merchant did not get upgraded to a
%macropayment.  It is therefore unclear how Peppercoin would actually
%reduce the computational burden on the exchange.


\section{Design}

The Taler system comprises three principal types of actors
(Figure~\ref{fig:cmm}): The \emph{customer} is interested in receiving
goods or services from the \emph{merchant} in exchange for payment.
When making a transaction, both the customer and the merchant use the
same \emph{exchange}, which serves as a payment service provider for
the financial transaction between the two.  The exchange is
responsible for allowing the customer to convert financial reserves to
the anonymous digital coins, and for enabling the merchant to convert
spent digital coins back to funds in a financial reserve.  In
addition, we describe an \emph{auditor} who assures customers and
merchants that the exchange operates correctly.

\subsection{Security model}

Taler's security model assumes that cryptographic primitives are
secure and that each participant is under full control of his system.
The contact information of the exchange is known to both customer and
merchant from the start.  We further assume that the customer can
authenticate the merchant, e.g. using X.509
certificates~\cite{rfc5280}.  Finally, we assume that customer has an
anonymous bi-directional channel, such as Tor, to communicate with
both the exchange and the merchant.

The exchange is trusted to hold funds of its customers and to forward
them when receiving the respective deposit instructions from the
merchants.  Customer and merchant can have assurances about the
exchange's liquidity and operation though published audits by
financial regulators or other trusted third parties.  If sufficently
regular, audits of the exchange's accounts should reveal any possible
fraud.  Online signing keys expire regularly, allowing the exchange to
destroy the corresponding accumulated cryptographic proofs.

The merchant is trusted to deliver the service or goods to the
customer upon receiving payment.  The customer can seek legal relief
to achieve this, as he receives cryptographic proofs of the contract
and has proof that he paid his obligations.

Neither the merchant nor the customer have any ability to {\em effectively}
defraud the exchange or the state collecting taxes.  Here, ``effectively''
means that the expected return for fraud is negative.
%
Note that customers do not need to be trusted in any way, and that in
particular it is never necessary for anyone to try to recover funds
from customers using legal coersion.

\subsection{Taxability and Entities}

Taler ensures that the state can tax {\em transactions}.  We must,
howerver, clarify what constitutes a transaction that can be taxed.
For ethical and practical reasons, we assume that coins can freely be
copied between machines, and that coin deletion cannot be verified.
Avoiding these assumptions would require extreme measures, like custom
hardware supplied by the exchange.  Also, it would be inappropriate to
tax the moving of funds between two computers owned by the same
entity.  Finally, we assume that at the time digital coins are
withdrawn, the wallet receiving the coins is owned by the individual
who is performing the authentication to authorize the withdrawal.
Preventing the owner of the reserve from deliberately authorizing
someone else to withdraw electronic coins would require extreme
measures, including preventing them from communicating with anyone but
the exchange terminal during withdrawal.  As such measures would be
totally impractical for a minor loophole, we are not concerned with
enabling the state to strongly identify the recipient of coins
from a withdrawal operation.

We view ownership of a coin's private key as a ``capability'' to spend
the funds.  A taxable transaction occurs when a merchant entity gains
control over the funds while at the same time a customer entity looses
control over the funds in a manner verifiable to the merchant.  In
other words, we restrict the definition of taxable transactions to
those transfers of funds where the recipient merchant is distrustful
of the spending customer, and requires verification that the customer
lost the capability to spend the funds.

Conversely, if a coin's private key is shared between two entities,
then both entities have equal access to the credentials represented by
the private key.  In a payment system, this means that either entity
could spend the associated funds.  Assuming the payment system has
effective double-spending detection, this means that either entity has
to constantly fear that the funds might no longer be available to it.
It follows that sharing coins by copying a private key implies mutual
trust between the two parties, in which case we treat them as the same
entity for taxability.

In Taler, making funds available by copying a private key and thus
sharing control is {\bf not} considered a {\em transaction} and thus
{\bf not} recorded for taxation.  Taler does, however, ensure
taxability when a merchant entity acquires exclusive control over the
value represented by a digital coins.  For such transactions, the state
can obtain information from the exchange, or a bank, that identifies
the entity that received the digital coins as well as the exact value
of those coins.  Taler also allows the exchange, and hence the state,
to learn the value of digital coins withdrawn by a customer---but not
how, where, or when they were spent.

\subsection{Anonymity}

We assume that an anonymous communication channel
such as Tor~\cite{tor-design} is
used for all communication between the customer and the merchant,
as well as for refreshing tainted coins with the exchange and for
retrieving the exchange's denomination key.
Ideally, the customer's anonymity is limited only by this channel;
however, the payment system does additionally reveal that the customer
is one of the patrons of the exchange.
There are naturally risks that the customer-merchant business operation
may leak identifying information about the customer.
We consider information leakage specific to the business logic to be
outside of the scope of the design of Taler.

Aside from refreshing and obtaining denomination key, the customer
should ideally use an anonymous communication channel with the exchange
to obscure their IP address for location privacy, but naturally
the exchange would typically learn the customer's identity from the wire
transfer that funds the customer's withdrawal of anonymous digital coins.
We believe this may even be desirable as there are laws, or bank policies,
that limit the amount of cash that an individual customer can withdraw
in a given time period~\cite{france2015cash,greece2015cash}.
Taler is thus only anonymous with respect to {\em payments}.
In particular, the exchange
is unable to link the known identity of the customer that withdrew
anonymous digital coins to the {\em purchase} performed later at the
merchant.

While the customer thus has anonymity for purchases, the exchange will
always learn the merchant's identity in order to credit the merchant's
account.  This is also necessary for taxation, as Taler deliberately
exposes these events as anchors for tax audits on income.

% Technically, the merchant could still
%use an anonymous communication channel to communicate with the exchange.
%However, in order to receive the traditional currency the exchange will
%require (SEPA) account details for the deposit.

%As both the initial transaction between the customer and the exchange as
%well as the transactions between the merchant and the exchange do not have
%to be done anonymously, there might be a formal business contract
%between the customer and the exchange and the merchant and the exchange.  Such
%a contract may provide customers and merchants some assurance that
%they will actually receive the traditional currency from the exchange
%given cryptographic proof about the validity of the transaction(s).
%However, given the business overheads for establishing such contracts
%and the natural goal for the exchange to establish a reputation and to
%minimize cost, it is more likely that the exchange will advertise its
%external auditors and proven reserves and thereby try to convince
%customers and merchants to trust it without a formal contract.


\subsection{Coins}

A \emph{coin} in Taler is a public-private key pair where the private
key is only known to the owner of the coin.  A coin derives its
financial value from an RSA signature over a the full domain hash
(FDH) of the coin's public key.  An FDH is used so that ``one-more
forgery'' is provably hard assuming the RSA known-target inversion
problem is hard~cite[Theorem 12]{RSA-HDF-KTIvCTI}.  The exchange has
multiple RSA {\em denomination key} pairs available for blind-signing
coins of different value.

Denomination keys have an expiration date, before which any coins
signed with it must be spent or refreshed.  This allows the exchange
to eventually discard records of old transactions, thus limiting the
records that the exchange must retain and search to detect
double-spending attempts.  Furthermore, the exchange uses each
denomination key only for a limited number of coins.  In this way, if
a private denomination key were to be compromised, the exchange would
detect this once more coins were redeemed than the total that was
signed into existence using that denomination key.  In this case, the
exchange can allow authentic customers to exchange their unspent
coins that were signed with the compromised private key, while
refusing further anonymous transactions involving those coins.  As a
result, the financial damage of losing a private signing key can be
limited to at most twice the amount originally signed with that key.

We also ensure that the exchange cannot deanonymize users by signing
each coin with a fresh denomination key.  For this, exchanges are
required to publicly announce their denomination keys in advance.
These announcements are expected to be signed with an off-line
long-term private {\em master signing key} of the exchange and the
auditor.  Additionally, customers should obtain these announcements
using an anonymous communication channel.

Before a customer can withdraw a coin from the exchange, he has to pay
the exchange the value of the coin, as well as processing fees.  This
is done using other means of payment, such as wire transfers or by
having a financial {\em reserve} at the exchange.  Taler assumes that
the customer has a {\em withdrawal authorization key} to identify
himself as authorized to withdraw funds from the reserve.  By signing
the withdrawal request using this withdrawal authorization key, the
customer can prove to the exchange that he is authorized to withdraw
anonymous digital coins from his reserve.  The exchange records the
withdrawal message as proof that the reserve was debited correctly.

%To put it differently, unlike
%modern cryptocurrencies like BitCoin, Taler's design simply
%acknowledges that primitive accumulation~\cite{engels1844} predates
%the system and that a secure method to authenticate owners exists.

After a coin is issued, the customer is the only entity that knows the
private key of the coin, making him the \emph{owner} of the coin.  Due
to the use of blind signatures, the exchange does not even learn the
public key during the withdrawal process.  If the private key is
shared with others, they become co-owners of the coin.  Knowledge of
the private key of the coin enables the owner to spent the coin.


% \subsection{Coin spending}

A customer spends a coin at a merchant by cryptographically signing a
{\em deposit authorization} with the coin's private key.  A deposit
authorization specifies the fraction of the coin's value to be paid to
the merchant, the salted hash of a merchant's financial reserve
routing information and a {\em business transaction-specific hash}.
Taler exchanges ensure that all transactions involving the same coin
do not exceed the total value of the coin simply by requiring that
merchants clear transactions immediately with the exchange.

If the customer is cheating and the coin was already spent, the
exchange provides the previous deposit authorization as cryptographic
proof of the fraud to the merchant.  If the deposit authorization is
correct, the exchange transfers the funds to the merchant by crediting
the merchant's financial reserve, e.g. using a wire transfer.


\subsection{Refreshing Coins}

If only a fraction of a coin's value has been spent, or if a
transaction fails for other reasons, it is possible that a customer
has revealed the public key of a coin to a merchant, but not
ultimately spent the full value of the coin.  If the customer then
continues to directly use the coin in other transactions, merchants
and the exchange could link the various transactions as they all share
the same public key for the coin.  We call a coin {\em dirty} if its
public key is known to anyone but the owner.

To avoid linkability of transactions, Taler allows the owner of a
dirty coin to exchange it for a {\em fresh} coin using the {\em coin
  refreshing protocol}.  Even if a coin is not dirty, the owner of a
coin may want to exchange it if the respective denomination key is
about to expire.  The {\em coin refreshing protocol}, allows the owner
of a coin to {\em melt} it for fresh coins of the same total value with a
new public-private key pairs.  Refreshing does not use the ordinary
spending operation as the owner of a coin should not have to pay
(income) taxes for refreshing.  However, to ensure that refreshing is
not used for money laundering or tax evasion, the refreshing protocol
assures that the owner stays the same.

The refresh protocol has two key properties: First, the exchange is
unable to link the fresh coin's public key to the public key of the
dirty coin.  Second, it is assured that the owner of the dirty coin
can determine the private key of the fresh coin, thereby preventing
the refresh protocol from being used to transfer ownership.


\section{Taler's Cryptographic Protocols}

\def\KDF{\textrm{KDF}}
\def\FDH{\textrm{FDH}}

% In this section, we describe the protocols for Taler in detail.

For the sake of brevity we omit explicitly saying each time that a
recipient of a signed message always first checks that the signature
is valid.  Furthermore, the receiver of a signed message is either
told the respective public key, or knows it from the context.  Also,
all signatures contain additional identification as to the purpose of
the signature, making it impossible to use a signature in a different
context.

An exchange has a long-term offline key which is used to certify
denomination keys and {\em online message signing keys} of the
exchange.  {\em Online message signing keys} are used for signing
protocol messages; denomination keys are used for blind-signing coins.
The exchange's long-term offline key is assumed to be known to both
customers and merchants and is certified by the auditors.

We avoid asking either customers or merchants to make trust desissions
about individual exchanges.  Instead, they need only select the auditors.
Auditors must sign all the exchange's keys including, the individual
denomination keys.

As we are dealing with financial transactions, we explicitly describe
whenever entities need to safely commit data to persistent storage.
As long as those commitments persist, the protocol can be safely
resumed at any step.  Commitments to disk are cumulative, that is an
additional commitment does not erase the previously committed
information.  Keys and thus coins always have a well-known expiration
date; information committed to disk can be discarded after the
expiration date of the respective public key.
Customers may discard information once the respective coins have been
fully spent, so long as refunds are not required.
Merchants may discard information once payments from the exchange have
been received, assuming the records are also no longer needed for tax
purposes.  The exchange's bank transfers dealing in traditional currency
are expected to be recorded for tax authorities to ensure taxability.
% FIXME: Auditor?

We use RSA for denomination keys and EdDSA over some eliptic curve
$\mathbb{E}$ for all other keys.  Let $G$ denote the generator of
our elliptic curve $\mathbb{E}$.


\subsection{Withdrawal}

To withdraw anonymous digital coins, the customer first selects an
exchange and one of its public denomination public keys $K_p$ whose
value $K_v$ corresponds to an amount the customer wishes to withdraw.
We let $K_s$ denote the exchange's private key corresponding to $K_p$.
Now the customer carries out the following interaction with the exchange:

% FIXME: We say withdrawal key in this document, but say reserve key in
% others, so probably withdrawal key should be renamed to reserve key.

% FIXME: These steps occur at very different points in time, so probably
% they should be restructured into more of a protocol discription.
% It does create some confusion, like is a withdrawal key semi-ephemeral
% like a linking key?

\begin{enumerate}
  \item The customer randomly generates:
    \begin{itemize}
      \item withdrawal key $W := (w_s,W_p)$ with private key $w_s$ and public key $W_p$,
      \item coin key $C := (c_s,C_p)$ with private key $c_s$ and public key $C_p := c_s G$,
      \item blinding factor $b$, and commits $\langle W, C, b \rangle$ to disk.
    \end{itemize}
  \item The customer transfers an amount of money corresponding to at least $K_v$
    to the exchange, with $W_p$ in the subject line of the transaction.
  \item The exchange receives the transaction and credits the $W_p$ reserve with
    the respective amount in its database.
  \item The customer sends $S_W(B)$ where $B := B_b(\FDH_K(C_p))$ to the exchange
    to request withdrawal of $C$; here, $B_b$ denotes Chaum-style blinding with
    blinding factor $b$.
  \item The exchange checks if the same withdrawal request was issued before;
    in this case, it sends $S_K(B)$ to the customer.%
\footnote{$S_K$ denotes a Chaum-style blind signature with private key $K_s$.}
    If this is a fresh withdrawal request, the exchange performs the following transaction:
    \begin{enumerate}
      \item checks if the reserve $W_p$ has sufficient funds
            for a coin of value corresponding to $K$
      \item stores the withdrawal request and response
            $\langle S_W(B), S_K(B) \rangle$ in its database
            for future reference,
      \item deducts the amount corresponding to $K$ from the reserve,
    \end{enumerate}
    and then sends $S_K(B)$ to the customer.
    If the guards for the transaction fail, the exchange sends a descriptive
    error back to the customer, with proof that it operated correctly.
    Assuming the signature was valid, this would involve showing the transaction
    history for the reserve.
        % FIXME: Is it really the whole history?
  \item The customer computes and verifies the unblinded signature
    $S_K(\FDH_K{C_p}) = U_b(S_K(B))$.
    Finally the customer saves the coin $\langle S_K(\FDH_K(C_p)), c_s \rangle$
    to their local wallet on disk.
\end{enumerate}


\subsection{Exact and partial spending}

A customer can spend coins at a merchant, under the condition that the
merchant trusts the exchange that issued the coin.
% FIXME: Auditor here?
Merchants are identified by their public key $M_p = m_s G$ which the
customer's wallet learns through the merchant's webpage, which itself
must be authenticated with X.509c.
% FIXME: Is this correct?

We now describe the protocol between the customer, merchant, and exchange
for a transaction in which the customer spends a coin $C := (c_s, C_p)$
with signature $\widetilde{C} := S_K(\FDH_K(C_p))$
 where $K$ is the exchange's demonination key.

% FIXME: Again, these steps occur at different points in time, maybe
% that's okay, but refresh is slightly different.

\begin{enumerate}
\item\label{contract}
  Let $\vec{D} := D_1, \ldots, D_n$ be the list of exchanges accepted by
  the merchant where each $D_j$ is a exchange's public key.
  The merchant creates a digitally signed contract
    $\mathcal{A} := S_M(m, f, a, H(p, r), \vec{D})$
  where $m$ is an identifier for this transaction, $a$ is data relevant
  to the contract indicating which services or goods the merchant will
  deliver to the customer, $f$ is the price of the offer, and
  $p$ is the merchant's payment information (e.g. his IBAN number), and
  $r$ is a random nonce.  The merchant commits $\langle \mathcal{A} \rangle$
  to disk and sends $\mathcal{A}$ to the customer.
\item\label{deposit}
  The customer should already possess a coin issued by a exchange that is
  accepted by the merchant, meaning $K$ should be publicly signed by
  some $D_j \in \{D_1, D_2, \ldots, D_n\}$, and has a value $\geq f$.
\item  The customer generates a \emph{deposit-permission} $\mathcal{D} :=
  S_c(\widetilde{C}, m, f, H(a), H(p,r), M_p)$
  and sends $\langle \mathcal{D}, D_j\rangle$ to the merchant,
  where $D_j$ is the exchange which signed $K$.
\item The merchant gives $(\mathcal{D}, p, r)$ to the exchange, thereby
  revealing $p$ only to the exchange.
\item The exchange validates $\mathcal{D}$ and checks for double spending.
  If the coin has been involved in previous transactions and the new
  one would exceed its remaining value, it sends an error
  with the records from the previous transactions back to the merchant.
%
  If double spending is not found, the exchange commits $\langle \mathcal{D} \rangle$ to disk
  and notifies the merchant that the deposit operation was successful.
\item The merchant commits and forwards the notification from the exchange to the
  customer, confirming the success or failure of the operation.
\end{enumerate}

We have simplified the exposition by assuming that one coin suffices,
but in practice a customer can use multiple coins from the same
exchange where the total value adds up to $f$ by running the above
steps for each of the coins.

If a transaction is aborted after Step~\ref{deposit},
subsequent transactions with the same coin could be linked to the coin,
but not directly to the coin's owner.  The same applies to partially
spent coins where $f$ is smaller than the actual value of the coin.
To unlink subsequent transactions from a coin, the customer has to
execute the coin refreshing protocol with the exchange.

%\begin{figure}[h]
%\centering
%\begin{tikzpicture}
%
%\tikzstyle{def} = [node distance= 1em, inner sep=.5em, outer sep=.3em];
%\node (origin) at (0,0) {};
%\node (offer) [def,below=of origin]{make offer (merchant $\rightarrow$ customer)};
%\node (A) [def,below=of offer]{permit lock (customer $\rightarrow$ merchant)};
%\node (B) [def,below=of A]{apply lock (merchant $\rightarrow$ exchange)};
%\node (C) [def,below=of B]{confirm (or refuse) lock (exchange $\rightarrow$ merchant)};
%\node (D) [def,below=of C]{sign contract (merchant $\rightarrow$ customer)};
%\node (E) [def,below=of D]{permit deposit (customer $\rightarrow$ merchant)};
%\node (F) [def,below=of E]{make deposit (merchant $\rightarrow$ exchange)};
%\node (G) [def,below=of F]{transfer confirmation (exchange $\rightarrow$ merchant)};
%
%\tikzstyle{C} = [color=black, line width=1pt]
%\draw [->,C](offer) -- (A);
%\draw [->,C](A) -- (B);
%\draw [->,C](B) -- (C);
%\draw [->,C](C) -- (D);
%\draw [->,C](D) -- (E);
%\draw [->,C](E) -- (F);
%\draw [->,C](F) -- (G);
%
%\draw [->,C, bend right, shorten <=2mm] (E.east)
%      to[out=-135,in=-45,distance=3.8cm] node[left] {aggregate} (D.east);
%\end{tikzpicture}
%\caption{Interactions between a customer, merchant and exchange in the coin spending
%  protocol}
%\label{fig:spending_protocol_interactions}
%\end{figure}


\subsection{Refreshing} \label{sec:refreshing}

We now describe the refresh protocol whereby a dirty coin $C'$ of
denomination $K$ is melted to obtain a fresh coin $\widetilde{C}$
with the same denomination.  In practice, Taler uses a natural
extension where multiple fresh coins are generated a the same time to
enable giving precise change matching any amount.
In the protocol, $\kappa \ge 3$ is a security parameter and $G$ is the
generator of the elliptic curve.

% FIXME: I'm explicit about the rounds in postquantum.tex

\begin{enumerate}
  \item For each $i = 1,\ldots,\kappa$, the customer randomly generates
     a transfer private key $t^{(i)}_s$ and computes
    \begin{itemize}
    \item the transfer public key $T^{(i)}_p := t^{(i)}_s G$ and
    \item the new coin secret seed $L_i := H(c'_s T_p^{(i)})$.
    \end{itemize}
    We have computed $L_i$ as a Diffie-Hellman shared secret between
    the transfer key pair $T^{(i)} := \left(t^{(i)}_s,T^{(i)}_p\right)$
    and old coin key pair $C' := \left(c_s', C_p'\right)$,
     so that $L_i = H(t^{(i)}_s C'_p)$ too.
    Now the customer applies key derivtion functions $\KDF_?$ to $L_i$ to generate
    \begin{itemize}
      \item a blinding factor $b^{(i)} = \FDH_K(\KDF_{\textrm{blinding}}(L_i))$.
      \item $c_s^{(i)} = \KDF_{\textrm{Ed25519}}(L_i)$
    \end{itemize}
    Now the customer can compute her new coin key pair
     $C^{(i)} := \left(c_s^{(i)}, C_p^{(i)}\right)$
     where $C^{(i)}_p := c^{(i)}_s G$.

    The customer saves to disk $\langle C', \vec{t}\rangle$ where
    $\vec{t} = \langle t^{(1)}_s, \ldots, t^{(\kappa)}_s \rangle$.
    We observe that $t^{(i)}_s$ suffices to regenerate $C^{(i)}$ and $b^{(i)}$
    using the same key derivtion functions.

  % \item
    The customer computes $B^{(i)} := B_{b^{(i)}}(\FDH_K(C^{(i)}_p))$ 
    for $i \in \{1,\ldots,\kappa\}$ and sends a commitment
     $S_{C'}(\vec{B}, \vec{T_p})$ to the exchange.
  \item The exchange generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and
    marks $C'_p$ as spent by committing
    $\langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$ to disk.
    Auditing processes should assure that $\gamma$ is unpredictable until
    this time to prevent the exchange from assisting tax evasion.
  \item The exchange sends $S_{K'}(C'_p, \gamma)$ to the customer where
    $K'$ is the exchange's message signing key.
  \item The customer commits $\langle C', S_K(C'_p, \gamma) \rangle$ to disk.

  % \item
    Also, the customer computes $\mathfrak{R} := \left(t_s^{(i)}\right)_{i \ne \gamma}$
      and sends $S_{C'}(\mathfrak{R})$ to the exchange.
  \item \label{step:refresh-ccheck} 
    The exchange checks whether $\mathfrak{R}$ is consistent with
    the commitments; specifically, it computes for $i \not= \gamma$:

    \vspace{-2ex}
    \begin{minipage}{5cm}
    \begin{align*}
      \overline{K}_i :&= H(t_s^{(i)} C_p') \\
      \overline{c}_s^{(i)} :&= \KDF_{\textrm{Ed25519}}(\overline{K}_i) \\
      \overline{C^{(i)}_p} :&= \overline{c}_s^{(i)} G
     \end{align*}
    \end{minipage}
    \begin{minipage}{5cm}
     \begin{align*}
       \overline{T_p^{(i)}} :&= t_s^{(i)} G \\ 
       \overline{b}^{(i)} :&= \FDH_K(\KDF_{\textrm{blinding}}(\overline{K}_i)) \\
       \overline{B^{(i)}} :&= B_{\overline{b_i}}(\overline{C_p^{(i)}}) 
     \end{align*}
    \end{minipage}

    and checks if $\overline{B^{(i)}} = B^{(i)}$
    and $\overline{T^{(i)}_p} = T^{(i)}_p$.

  \item \label{step:refresh-done} 
    If the commitments were consistent, the exchange sends the
    blind signature $\widetilde{C} := S_{K}(B^{(\gamma)})$ to the customer.
    Otherwise, the exchange responds with an error indicating
     the location of the failure.
\end{enumerate}

%\subsection{N-to-M Refreshing}
%
%TODO: Explain, especially subtleties regarding session key / the spoofing attack that requires signature.

\subsection{Linking}

% FIXME: What is \mathtt{link} ?

For a coin that was successfully refreshed, the exchange responds to a
request $S_{C'}(\mathtt{link})$ with $(T^{(\gamma)}_p, \widetilde{C})$.
%
This allows the owner of the melted coin to derive the private key of
the new coin, even if the refreshing protocol was illicitly executed
with the help of another party who generated $\vec{c_s}$ and only
provided $\vec{C_p}$ and other required information to the old owner.
As a result, linking ensures that access to the new coins issued in
the refresh protocol is always {\em shared} with the owner of the
melted coins.  This makes it impossible to abuse the refresh protocol
for {\em transactions}.

The linking request is not expected to be used at all during ordinary
operation of Taler.  If the refresh protocol is used by Alice to
obtain change as designed, she already knows all of the information
and thus has little reason to request it via the linking protocol.
The fundamental reason why the exchange must provide the link protocol 
is simply to provide a threat: if Bob were to use the refresh protocol
for a transaction of funds from Alice to him, Alice may use a link
request to gain shared access to Bob's coins. Thus, this threat
prevents Alice and Bob from abusing the refresh protocol to evade
taxation on transactions. If Bob trusts Alice to not execute the link
protocol, then they can already conspire to evade taxation by simply
exchanging the original private coin keys.  This is permitted in our
taxation model as with such trust they are assumed to be the same
entity.

The auditor can anonymously check if the exchange correctly implements the
link request, thus preventing the exchange operator from legally disabling
this protocol component.  Without the link operation, Taler would
devolve into a payment system where both sides can be anonymous, and
thus no longer provide taxability.


\subsection{Error handling}

During operation, there are three main types of errors that are
expected.  First, in the case of faulty clients, the responding server
will generate an error message with detailed cryptographic proofs
demonstrating that the client was faulty, for example by providing
proof of double-spending or providing the previous commit and the
location of the missmatch in the case of the reveal step in the
refresh protocol.  It is also possible that the server may claim that
the client has been violating the protocol.  In these cases, the
clients should verify any proofs provided and if they are acceptable,
notify the user that they are somehow faulty.  Similar, if the
server indicates that the client is violating the protocol, the
client should record the interaction and enable the user to file a
bug report.

The second case is a faulty exchange service provider.  Here, faults
will be detected when the exchange provides a faulty proof or no
proof.  In this case, the client is expected to notify the auditor,
providing a transcript of the interaction.  The auditor can then
anonymously replay the transaction, and either provide the now correct
response to the client or take appropriate legal action against the
faulty exchange.

The third case are transient failures, such as network failures or
temporary hardware failures at the exchange service provider.  Here, the
client may receive an explicit protocol indication, such as an HTTP
response code 500 ``internal server error'' or simply no response.
The appropriate behavior for the client is to automatically retry
after 1s, and twice more at randomized times within 1 minute.
If those three attempts fail, the user should be informed about the
delay.  The client should then retry another three times within the
next 24h, and after that time the auditor be informed about the outage.

Using this process, short term failures should be effectively obscured
from the user, while malicious behavior is reported to the auditor who
can then presumably rectify the situation, using methods such as
shutting down the operator and helping customers to regain refunds for
coins in their wallets.  To ensure that such refunds are possible, the
operator is expected to always provide adequate securities for the
amount of coins in circulation as part of the certification process.


%As with support for fractional payments, Taler addresses these
%problems by allowing customers to refresh tainted coins, thereby
%destroying the link between the refunded or aborted transaction and
%the new coin.


\subsection{Refunds}

The refresh protocol offers an easy way to enable refunds to
customers, even if they are anonymous.  Refunds can be supported
by including a public signing key of the merchant in the transaction
details, and having the customer keep the private key of the spent
coins on file.

Given this, the merchant can simply sign a {\em refund confirmation}
and share it with the exchange and the customer.  Assuming the
exchange has a way to recover the funds from the merchant, or has not
yet performed the wire transfer, the exchange can simply add the value
of the refunded transaction back to the original coin, re-enabling
those funds to be spent again by the original customer.  This customer
can then use the refresh protocol to anonymously melt the refunded
coin and create a fresh coin that is unlinkable to the refunded
transaction.

\section{Experimental results}

\begin{figure}[b!]
  \begin{subfigure}{0.45\columnwidth}
    \includegraphics[width=\columnwidth]{bw_in.png}
    \caption{Incoming traffic at the exchange, in bytes per 5 minutes.}
    \label{fig:in}
  \end{subfigure}\hfill
  \begin{subfigure}{0.45\columnwidth}
    \includegraphics[width=\columnwidth]{bw_out.png}
    \caption{Outgoing traffic from the exchange, in bytes per 5 minutes.}
    \label{fig:out}
  \end{subfigure}
  \begin{subfigure}{0.45\columnwidth}
    \includegraphics[width=\columnwidth]{db_read.png}
    \caption{DB read operations per second.}
    \label{fig:read}
  \end{subfigure}
  \begin{subfigure}{0.45\columnwidth}
    \includegraphics[width=\columnwidth]{db_write.png}
    \caption{DB write operations per second.}
    \label{fig:write}
   \end{subfigure}
  \begin{subfigure}{0.45\columnwidth}
    \includegraphics[width=\columnwidth]{cpu_balance.png}
    \caption{CPU credit balance. Hitting a balance of 0 shows the CPU is
       the limiting factor.}
    \label{fig:cpu}
  \end{subfigure}\hfill
  \begin{subfigure}{0.45\columnwidth}
    \includegraphics[width=\columnwidth]{cpu_usage.png}
    \caption{CPU utilization. The t2.micro instance is allowed to use 10\% of
       one CPU.}
    \label{fig:usage}
  \end{subfigure}
  \caption{Selected EC2 performance monitors for the experiment in the EC2
           (after several hours, once the system was ``warm'').}
  \label{fig:ec2}
\end{figure}

We ran the Taler exchange v0.0.2 on an Amazon EC2 t2.micro instance
(10\% of a Xeon E5-2676 at 2.4 GHz) based on Ubuntu 14.04.4 LTS, using
a db.t2.micro instance with Postgres 9.5 for the database.  Using 16
concurrent clients performing withdraw, deposit and refresh operations
we then pushed the t2.micro instance to the resource limit
(Figure~\ref{fig:cpu}) from a network with $\approx$ 160 ms latency to
the EC2 instance.  At that point, the instance managed about 8 HTTP
requests per second, which roughly corresponds to one full business
transaction (as a full business transaction is expected to involve
withdrawing and depositing several coins).  The network traffic was
modest at approximately 50 kbit/sec from the exchange
(Figure~\ref{fig:out}) and 160 kbit/sec to the exchange
(Figure~\ref{fig:in}).  At network latencies above 10 ms, the delay
for executing a transaction is dominated by the network latency, as
local processing virtually always takes less than 10 ms.

Database transactions are dominated by writes (Figure~\ref{fig:read}
vs.  Figure~\ref{fig:write}), as Taler mostly needs to log
transactions and occasionally needs to read to guard against
double-spending.  Given a database capacity of 2 TB---which should
suffice for more than one year of full transaction logs---the
described setup has a hosting cost within EC2 of approximately USD 252
per month, or roughly 0.0001 USD per full business transaction.  This
compares favorably to the $\approx$ USD 10 per business transaction
for Bitcoin and the \EUR{0.35} plus 1.9\% charged by Paypal for
domestic transfers within Germany.

In the Amazon EC2 billing, the cost for the database (using SSD
storage) dominates the cost with more than USD 243 per month.  We note
that these numbers are approximate, as the frontend and backend in our
configuration uses systems from the AWS Free Usage Tier and is not
perfectly balanced in between frontend and backend.  Nevertheless,
these experimental results show that computing-related business costs
will only marginally contribute to the operational costs of the Taler
payment system.



\section{Discussion}

Taler was designed for use in a modern social-liberal society and
provides a payment system with the following key properties:

\begin{description}
  \item[Customer Anonymity]
    It is impossible for exchanges, merchants and even a global active
    adversary, to trace the spending behavior of a customer.
    As a strong form of customer anonymity, it is also infeasible to
    link a set of transactions to the same (anonymous) customer.
    %, even when taking aborted transactions into account.

    There is, however, a risk of metadata leakage if a customer
    acquires coins matching exactly the price quoted by a merchant, or
    if a customer uses coins issued by multiple exchanges for the same
    transaction.  Hence, our implementation does not allow this.

  \item[Taxability]
    In many current legal systems, it is the responsibility of the merchant
    to deduct sales taxes from purchases made by customers, or for workers
    to pay income taxes for payments received for work.
    Taler ensures that merchants are easily identifiable and that
    an audit trail is generated, so that the state can ensure that its
    taxation regime is obeyed.
  \item[Verifiability]
    Taler minimizes the trust necessary between
    participants.  In particular, digital signatures are retained
    whenever they would play a role in resolving disputes.
    Additionally, customers cannot defraud anyone, and
    merchants can only defraud their customers by not
    delivering on the agreed contract.  Neither merchants nor customers
    are able to commit fraud against the exchange.
    Only the exchange needs be tightly audited and regulated.
  \item[No speculation] % It's actually "Specualtion not required"
    The digital coins are denominated in existing currencies,
    such as EUR or USD.  This avoids exposing citizens to unnecessary risks
    from currency fluctuations.
  \item[Low resource consumption]
    The design minimizes the operating costs and environmental impact of
    the payment system.  It uses few public key operations per
    transaction and entirely avoids proof-of-work computations.
    The payment system handles both small and large payments in
    an efficient and reliable manner.
\end{description}


\subsection{Well-known attacks}

Taler's security is largely equivalent to that of Chaum's original
design without online checks or the cut-and-choose revelation of
double-spending customers for offline spending.
We specifically note that the digital equivalent of the ``Columbian
Black Market Exchange''~\cite{fatf1997} is a theoretical problem for
both Chaum and Taler, as individuals with a strong mutual trust
foundation can simply copy electronic coins and thereby establish a
limited form of black transfers.  However, unlike the situation with
physical checks with blank recipients in the Columbian black market,
the transitivity is limited as each participant can deposit the electronic
coins and thereby cheat any other participant, while in the Columbian
black market each participant only needs to trust the issuer of the
check and not also all previous owners of the physical check.

As with any unconditionally anonymous payment system, the ``Perfect
Crime'' attack~\cite{solms1992perfect} where blackmail is used to
force the exchange to issue anonymous coins also continues to apply in
principle.  However, as mentioned Taler does facilitate limits on
withdrawals, which we believe is a better trade-off than the
problematic escrow systems where the necessary intransparency
actually facilitates voluntary cooperation between the exchange and
criminals~\cite{sander1999escrow} and where the state could
deanonymize citizens.

\subsection{Offline Payments}

Chaum's original proposals for anonymous digital cash avoided the need
for online interactions with the exchange to detect double spending by
providing a means to deanonymize customers involved in
double-spending.  This is problematic as the exchange or the merchant
still need out-of-band means to recover funds from the customer, which
may be infeasible in practice.  Furthermore, a customer may
accidentally deanonymize himself, for example by double-spending a
coin after restoring from backup.

%\subsection{Merchant Tax Audits}
%
%For a tax audit on the merchant, the exchange includes the business
%transaction-specific hash in the transfer of the traditional
%currency.  A tax auditor can then request the merchant to reveal
%(meaningful) details about the business transaction ($\mathcal{D}$,
%$a$, $p$, $r$), including proof that applicable taxes were paid.
%
%If a merchant is not able to provide theses values, he can be
%subjected to financial penalties by the state in relation to the
%amount transferred by the traditional currency transfer.

\subsection{Cryptographic proof vs. evidence}

In this paper we have use the term ``proof'' in many places as the
protocol provides cryptographic proofs of which parties behave
correctly or incorrectly. However, as~\cite{fc2014murdoch} point out,
in practice financial systems need to provide evidence that holds up
in courts.  Taler's implementation is designed to export evidence and
upholds the core principles described in~\cite{fc2014murdoch}.  In
particular, in providing the cryptographic proofs as evidence none of
the participants have to disclose their core secrets.


%\subsection{System Performance}
%
%We performed some initial performance measurements for the various
%operations on our exchange implementation.  The main conclusion was that
%the computational and bandwidth cost for transactions described in
%this paper is smaller than $10^{-3}$ cent/transaction, and thus
%dwarfed by the other business costs for the exchange.  However, this
%figure excludes the cost of currency transfers using traditional
%banking, which a exchange operator would ultimately have to interact with.
%Here, exchange operators should be able to reduce their expenses by
%aggregating multiple transfers to the same merchant.


%\section{Conclusion}

%We have presented an efficient electronic payment system that
%simultaneously addresses the conflicting objectives created by the
%citizen's need for privacy and the state's need for taxation.  The
%coin refreshing protocol makes the design flexible and enables a
%variety of payment methods.  The current balance and profits of the
%exchange are also easily determined, thus audits can be used to ensure
%that the exchange operates correctly.  The libre implementation and open
%protocol may finally enable modern society to upgrade to proper
%electronic wallets with efficient, secure and privacy-preserving
%transactions.

% commented out for anonymized submission
%\subsection*{Acknowledgements}

%This work was supported by a grant from the Renewable Freedom Foundation.
% FIXME: ARED?
%We thank Tanja Lange, Dan Bernstein, Luis Ressel and Fabian Kirsch for feedback on an earlier
%version of this paper, Nicolas Fournier for implementing and running
%some performance benchmarks, and Richard Stallman, Hellekin Wolf,
%Jacob Appelbaum for productive discussions and support.


\bibliographystyle{alpha}
\bibliography{taler,rfc}

\vfill
\begin{center}
 \Large  Demonstration available at \url{https://demo.taler.net/}
\end{center}
\vfill

\newpage
\appendix

\section{Notation summary}

The paper uses the subscript $p$ to indicate public keys and $s$ to
indicate secret (private) keys.  For keys, we also use small letters
for scalars and capital letters for points on an elliptic curve.  The
capital letter without the subscript $p$ stands for the key pair.  The
superscript $(i)$ is used to indicate one of the elements of a vector
during the cut-and-choose protocol.  Bold-face is used to indicate a
vector over these elements.  A line above indicates a value computed
by the verifier during the cut-and-choose operation.  We use $f()$ to
indicate the application of a function $f$ to one or more arguments. Records of
data being committed to disk are represented in between $\langle\rangle$.

\begin{description}
  \item[$K_s$]{Denomination private (RSA) key of the exchange used for coin signing}
  \item[$K_p$]{Denomination public (RSA) key corresponding to $K_s$}
  \item[$K$]{Public-priate (RSA) denomination key pair $K := (K_s, K_p)$}
  \item[$b$]{RSA blinding factor for RSA-style blind signatures}
  \item[$B_b()$]{RSA blinding over the argument using blinding factor $b$}
  \item[$U_b()$]{RSA unblinding of the argument using blinding factor $b$}
  \item[$S_K()$]{Chaum-style RSA signature, $S_K(C) = U_b(S_K(B_b(C)))$}
  \item[$w_s$]{Private key from customer for authentication}
  \item[$W_p$]{Public key corresponding to $w_s$}
  \item[$W$]{Public-private customer authentication key pair $W := (w_s, W_p)$}
  \item[$S_W()$]{Signature over the argument(s) involving key $W$}
  \item[$m_s$]{Private key from merchant for authentication}
  \item[$M_p$]{Public key corresponding to $m_s$}
  \item[$M$]{Public-private merchant authentication key pair $M := (m_s, M_p)$}
  \item[$S_M()$]{Signature over the argument(s) involving key $M$}
  \item[$G$]{Generator of the elliptic curve}
  \item[$c_s$]{Secret key corresponding to a coin, scalar on a curve}
  \item[$C_p$]{Public key corresponding to $c_s$, point on a curve}
  \item[$C$]{Public-private coin key pair $C := (c_s, C_p)$}
  \item[$S_{C}()$]{Signature over the argument(s) involving key $C$ (using EdDSA)}
  \item[$c_s'$]{Private key of a ``dirty'' coin (otherwise like $c_s$)}
  \item[$C_p'$]{Public key of a ``dirty'' coin (otherwise like $C_p$)}
  \item[$C'$]{Dirty coin (otherwise like $C$)}
  \item[$\widetilde{C}$]{Exchange signature $S_K(C_p)$ indicating validity of a fresh coin (with key $C$)}
  \item[$n$]{Number of exchanges accepted by a merchant}
  \item[$j$]{Index into a set of accepted exchanges, $i \in \{1,\ldots,n\}$}
  \item[$D_j$]{Public key of a exchange (not used to sign coins)}
  \item[$\vec{D}$]{Vector of $D_j$ signifying exchanges accepted by a merchant}
  \item[$a$]{Complete text of a contract between customer and merchant}
  \item[$f$]{Amount a customer agrees to pay to a merchant for a contract}
  \item[$m$]{Unique transaction identifier chosen by the merchant}
  \item[$H()$]{Hash function}
  \item[$p$]{Payment details of a merchant (i.e. wire transfer details for a bank transfer)}
  \item[$r$]{Random nonce}
  \item[${\cal A}$]{Complete contract signed by the merchant}
  \item[${\cal D}$]{Deposit permission, signing over a certain amount of coin to the merchant as payment and to signify acceptance of a particular contract}
  \item[$\kappa$]{Security parameter $\ge 3$}
  \item[$i$]{Index over cut-and-choose set, $i \in \{1,\ldots,\kappa\}$}
  \item[$\gamma$]{Selected index in cut-and-choose protocol, $\gamma \in \{1,\ldots,\kappa\}$}
  \item[$t^{(i)}_s$]{private transfer key, a scalar}
  \item[$T^{(i)}_p$]{public transfer key, point on a curve (same curve must be used for $C_p$)}
  \item[$T^{(i)}$]{public-private transfer key pair $T^{(i)} := (t^{(i)}_s,T^{(i)}_s)$}
  \item[$\vec{t}$]{Vector of $t^{(i)}_s$}
  \item[$c_s^{(i)}$]{Secret key corresponding to a fresh coin, scalar on a curve}
  \item[$C_p^{(i)}$]{Public key corresponding to $c_s^{(i)}$, point on a curve}
  \item[$C^{(i)}$]{Public-private coin key pair $C^{(i)} := (c_s^{(i)}, C_p^{(i)})$}
%  \item[$\vec{C}$]{Vector of $C^{(i)}$ (public and private keys)}
  \item[$b^{(i)}$]{Blinding factor for RSA-style blind signatures}
  \item[$\vec{b}$]{Vector of $b^{(i)}$}
  \item[$B^{(i)}$]{Blinding of $C_p^{(i)}$}
  \item[$\vec{B}$]{Vector of $B^{(i)}$}
  \item[$L_i$]{Link secret derived from ECDH operation via hashing}
%  \item[$E_{L_i}()$]{Symmetric encryption using key $L_i$}
%  \item[$E^{(i)}$]{$i$-th encryption of the private information $(c_s^{(i)}, b_i)$}
%  \item[$\vec{E}$]{Vector of $E^{(i)}$}
  \item[$\cal{R}$]{Tuple of revealed vectors in cut-and-choose protocol,
    where the vectors exclude the selected index $\gamma$}
  \item[$\overline{L_i}$]{Link secrets derived by the verifier from DH}
  \item[$\overline{B^{(i)}}$]{Blinded values derived by the verifier}
  \item[$\overline{T_p^{(i)}}$]{Public transfer keys derived by the verifier from revealed private keys}
  \item[$\overline{c_s^{(i)}}$]{Private keys obtained from decryption by the verifier}
  \item[$\overline{b_s^{(i)}}$]{Blinding factors obtained from decryption by the verifier}
  \item[$\overline{C^{(i)}_p}$]{Public coin keys computed from $\overline{c_s^{(i)}}$ by the verifier}
\end{description}



\end{document}








\section{Optional features}

In this appendix we detail various optional features that can
be added to the basic protocol to reduce transaction costs for
certain interactions.

However, we note that Taler's transaction costs are expected to be so
low that these features are likely not particularly useful in
practice: When we performed some initial performance measurements for
the various operations on our exchange implementation, the main conclusion
was that the computational and bandwidth cost for transactions
described in this paper is smaller than $10^{-3}$ cent/transaction,
and thus dwarfed by the other business costs for the exchange.  We note
that the $10^{-3}$ cent/transaction estimate excludes the cost of wire
transfers using traditional banking, which a exchange operator would
ultimately have to interact with.  Here, exchange operators should be able
to reduce their expenses by aggregating multiple transfers to the same
merchant.

As a result of the low cost of the interaction with the exchange in Taler
today, we expect that transactions with amounts below Taler's internal
transaction costs to be economically meaningless.  Nevertheless, we
document various ways how such transactions could be achieved within
Taler.



\subsection{Incremental spending}

For services that include pay-as-you-go billing, customers can over
time sign deposit permissions for an increasing fraction of the value
of a coin to be paid to a particular merchant.  As checking with the
exchange for each increment might be expensive, the coin's owner can
instead sign a {\em lock permission}, which allows the merchant to get
an exclusive right to redeem deposit permissions for the coin for a
limited duration.  The merchant uses the lock permission to determine
if the coin has already been spent and to ensure that it cannot be
spent by another merchant for the {\em duration} of the lock as
specified in the lock permission.  If the coin has insufficient funds
because too much has been spent or is
already locked, the exchange provides the owner's deposit or locking
request and signature to prove the attempted fraud by the customer.
Otherwise, the exchange locks the coin for the expected duration of the
transaction (and remembers the lock permission).  The merchant and the
customer can then finalize the business transaction, possibly
exchanging a series of incremental payment permissions for services.
Finally, the merchant then redeems the coin at the exchange before the
lock permission expires to ensure that no other merchant redeems the
coin first.

\begin{enumerate}
\item\label{offer2} The merchant sends an \emph{offer:} $\langle S_M(m, f),
  \vec{D} \rangle$ containing the price of the offer $f$, a transaction
  ID $m$ and the list of exchanges $D_1, \ldots, D_n$ accepted by the merchant
  where each $D_j$ is a exchange's public key.
\item\label{lock2} The customer must possess or acquire a coin $\widetilde{C}$
  signed by a exchange that is
  accepted by the merchant, i.e. $K$ should be signed by some $D_j
  \in \{D_1, D_2, \ldots, D_n\}$, and has a value $\geq f$.

  Customer then generates a \emph{lock-permission} $\mathcal{L} :=
  S_c(\widetilde{C}, t, m, f, M_p)$ where $t$ specifies the time until which the
  lock is valid and sends $\langle \mathcal{L}, D_j\rangle$ to the merchant,
  where $D_j$ is the exchange which signed $K$.
\item The merchant asks the exchange to apply the lock by sending $\langle
  \mathcal{L} \rangle$ to the exchange.
\item The exchange validates $\widetilde{C}$ and detects double spending
  in the form of existing \emph{deposit-permission} or
  lock-permission records for $\widetilde{C}$.  If such records exist
  and indicate that insufficient funds are left, the exchange sends those
  records to the merchant, who can then use the records to prove the double
  spending to the customer.

  If double spending is not found,
  the exchange commits $\langle \mathcal{L} \rangle$ to disk
  and notifies the merchant that locking was successful.
\item\label{contract2} The merchant creates a digitally signed contract
  $\mathcal{A} := S_M(m, f, a, H(p, r))$ where $a$ is data relevant to the contract
  indicating which services or goods the merchant will deliver to the customer, and $p$ is the
  merchant's payment information (e.g. his IBAN number) and $r$ is an random nonce.
  The merchant commits $\langle \mathcal{A} \rangle$ to disk and sends it to the customer.
\item The customer creates a
  \emph{deposit-permission} $\mathcal{D} := S_c(\widetilde{C}, \widetilde{L}, f, m, M_p, H(a), H(p, r))$, commits
  $\langle \mathcal{A}, \mathcal{D} \rangle$ to disk and sends $\mathcal{D}$ to the merchant.
\item\label{invoice_paid2} The merchant commits the received $\langle \mathcal{D} \rangle$ to disk.
\item The merchant gives $(\mathcal{D}, p, r)$ to the exchange, revealing his
  payment information.
\item The exchange verifies $(\mathcal{D}, p, r)$ for its validity and
  checks against double spending, while of
  course permitting the merchant to withdraw funds from the amount that
  had been locked for this merchant.
 \item If $\widetilde{C}$ is valid and no equivalent \emph{deposit-permission} for $\widetilde{C}$ and $\widetilde{L}$ exists on disk, the
  exchange performs the following transaction:
  \begin{enumerate}
    \item $\langle \mathcal{D}, p, r \rangle$ is committed to disk.
    \item\label{transfer2} transfers an amount of $f$ to the merchant's bank account
      given in $p$.  The subject line of the transaction to $p$ must contain
      $H(\mathcal{D})$.
  \end{enumerate}
  Finally, the exchange sends a confirmation to the merchant.
 \item If the deposit record $\langle \mathcal{D}, p, r \rangle$ already exists,
  the exchange sends the confirmation to the merchant,
  but does not transfer money to $p$ again.
\end{enumerate}

To facilitate incremental spending of a coin $C$ in a single transaction, the
merchant makes an offer in Step~\ref{offer2} with a maximum amount $f_{max}$ he
is willing to charge in this transaction from the coin $C$.  After obtaining the
lock on $C$ for $f_{max}$, the merchant makes a contract in Step~\ref{contract2}
with an amount $f \leq f_{max}$.  The protocol follows with the following steps
repeated after Step~\ref{invoice_paid2} whenever the merchant wants to charge an
incremental amount up to $f_{max}$:

\begin{enumerate}
  \setcounter{enumi}{4}
\item The merchant generates a new contract $ \mathcal{A}' := S_M(m, f', a', H(p,
  r)) $ after obtaining the deposit-permission for a previous contract.  Here
  $f'$ is the accumulated sum the merchant is charging the customer, of which
  the merchant has received a deposit-permission for $f$ from the previous
  contract \textit{i.e.}~$f <f' \leq f_{max}$.  Similarly $a'$ is the new
  contract data appended to older contract data $a$.
  The merchant commits $\langle \mathcal{A}' \rangle$ to disk and sends it to the customer.
\item Customer commits $\langle \mathcal{A}' \rangle$ to disk, creates
  $\mathcal{D}' := S_c(\widetilde{C}, \mathcal{L}, f', m, M_p, H(a'), H(p, r))$, commits
  $\langle \mathcal{D'} \rangle$ and sends it to the merchant.
\item The merchant commits the received $\langle \mathcal{D'} \rangle$ and
  deletes the older $\mathcal{D}$.
\end{enumerate}

%Figure~\ref{fig:spending_protocol_interactions} summarizes the interactions of the
%coin spending protocol.

For transactions with multiple coins, the steps of the protocol are
executed in parallel for each coin.  During the time a coin is locked,
the locked fraction may not be spent at a different merchant or via a
deposit permission that does not contain $\mathcal{L}$.  The exchange will
release the locks when they expire or are used in a deposit operation.
Thus the coins can be used with other merchants once their locks
expire, even if the original merchant never executed any deposit for
the coin.  However, doing so may link the new transaction to older
transaction.

Similarly, if a transaction is aborted after Step 2, subsequent
transactions with the same coin can be linked to the coin, but not
directly to the coin's owner.  The same applies to partially spent
coins.  Thus, to unlink subsequent transactions from a coin, the
customer has to execute the coin refreshing protocol with the exchange.

%\begin{figure}[h]
%\centering
%\begin{tikzpicture}
%
%\tikzstyle{def} = [node distance= 1em, inner sep=.5em, outer sep=.3em];
%\node (origin) at (0,0) {};
%\node (offer) [def,below=of origin]{make offer (merchant $\rightarrow$ customer)};
%\node (A) [def,below=of offer]{permit lock (customer $\rightarrow$ merchant)};
%\node (B) [def,below=of A]{apply lock (merchant $\rightarrow$ exchange)};
%\node (C) [def,below=of B]{confirm (or refuse) lock (exchange $\rightarrow$ merchant)};
%\node (D) [def,below=of C]{sign contract (merchant $\rightarrow$ customer)};
%\node (E) [def,below=of D]{permit deposit (customer $\rightarrow$ merchant)};
%\node (F) [def,below=of E]{make deposit (merchant $\rightarrow$ exchange)};
%\node (G) [def,below=of F]{transfer confirmation (exchange $\rightarrow$ merchant)};
%
%\tikzstyle{C} = [color=black, line width=1pt]
%\draw [->,C](offer) -- (A);
%\draw [->,C](A) -- (B);
%\draw [->,C](B) -- (C);
%\draw [->,C](C) -- (D);
%\draw [->,C](D) -- (E);
%\draw [->,C](E) -- (F);
%\draw [->,C](F) -- (G);
%
%\draw [->,C, bend right, shorten <=2mm] (E.east)
%      to[out=-135,in=-45,distance=3.8cm] node[left] {aggregate} (D.east);
%\end{tikzpicture}
%\caption{Interactions between a customer, merchant and exchange in the coin spending
%  protocol}
%\label{fig:spending_protocol_interactions}
%\end{figure}


\subsection{Probabilistic donations}

Similar to Peppercoin, Taler supports probabilistic {\em micro}donations of coins to
support cost-effective transactions for small amounts.  We consider
amounts to be ``micro'' if the value of the transaction is close or
even below the business cost of an individual transaction to the exchange.

To support microdonations, an ordinary transaction is performed based
on the result of a biased coin flip with a probability related to the
desired transaction amount in relation to the value of the coin.  More
specifically, a microdonation of value $\epsilon$ is upgraded to a
macropayment of value $m$ with a probability of $\frac{\epsilon}{m}$.
Here, $m$ is chosen such that the business transaction cost at the
exchange is small in relation to $m$.  The exchange is only involved in the
tiny fraction of transactions that are upgraded.  On average both
customers and merchants end up paying (or receiving) the expected
amount $\epsilon$ per microdonation.

Unlike Peppercoin, in Taler either the merchant wins and the customer
looses the coin, or the merchant looses and the customer keeps the
coin.  Thus, there is no opportunity for the merchant and the customer
to conspire against the exchange.  To determine if the coin is to be
transferred, merchant and customer execute a secure coin flipping
protocol~\cite{blum1981}.  The commit values are included in the
business contract and are revealed after the contract has been signed
using the private key of the coin.  If the coin flip is decided in
favor of the merchant, the merchant can redeem the coin at the exchange.

One issue in this protocol is that the customer may use a worthless
coin by offering a coin that has already been spent.  This kind of
fraud would only be detected if the customer actually lost the coin
flip, and at this point the merchant might not be able to recover from
the loss.  A fraudulent anonymous customer may run the protocol using
already spent coins until the coin flip is in his favor.

As with incremental spending, lock permissions could be used to ensure
that the customer cannot defraud the merchant by offering a coin that
has already been spent.  However, as this means involving the exchange
even if the merchant looses the coin flip, such a scheme is unsuitable
for microdonations as the transaction costs from involving the exchange
might be disproportionate to the value of the transaction, and thus
with locking the probabilistic scheme has no advantage over simply
using fractional payments.

Hence, Taler uses probabilistic transactions {\em without} online
double-spending detection.  This enables the customer to defraud the
merchant by paying with a coin that was already spent.  However, as,
by definition, such microdonations are for tiny amounts, the incentive
for customers to pursue this kind of fraud is limited.  Still, to
clarify that the customer must be honest, we prefer the term
micro{\em donations} over micro{\em payments} for this scheme.


The following steps are executed for microdonations with upgrade probability $p$:
\begin{enumerate}
  \item The merchant sends an offer to the customer.
  \item The customer sends a commitment $H(r_c)$ to a random
    value $r_c \in [0,2^R)$, where $R$ is a system parameter.
  \item The merchant sends random $r_m \in [0,2^R)$ to the customer.
    \item The customer computes $p' := (|r_c - r_m|) / (2^R)$.
    If $p' < p$, the customer sends a coin with deposit-permission to the merchant.
    Otherwise, the customer sends $r_c$ to the merchant.
  \item The merchant deposits the coin, or checks if $r_c$ is consistent
    with $H(r_c)$.
\end{enumerate}

Evidently the customer can ``cheat'' by aborting the transaction in
Step 3 of the microdonation protocol if the outcome is unfavorable ---
and repeat until he wins.  This is why Taler is suitable for
microdonations --- where the customer voluntarily contributes ---
and not for micropayments.

Naturally, if the donations requested are small, the incentive to
cheat for minimal gain should be quite low.  Payment software could
embrace this fact by providing an appeal to conscience in form of an
option labeled ``I am unethical and want to cheat'', which executes
the dishonest version of the payment protocol.

If an organization detects that it cannot support itself with
microdonations, it can always choose to switch to the macropayment
system with slightly higher transaction costs to remain in business.

\newpage