taler/exchange
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Corrections to sections 1 and 2

Browse Source 
Please check out the second to last paragraph of the introduction
as I'm not really happy with it.

There are spelling correction elsewhere as I ran ispell, not sure if
I accedentally switched somew ords from British to American spelling.
This commit is contained in:
Jeff Burdges 2015-10-07 16:39:03 +02:00
parent bdc8bc7de3
commit 2863132570
1 changed files with 116 additions and 119 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

235
doc/paper/taler.tex
View File

@ -110,12 +110,12 @@ current payment systems which enable either an authoritarian state in
total control of the population, or create weak states with almost total control of the population, or create weak states with almost
anarchistic economies. anarchistic economies.
The Taler protocol is havily based on ideas from The Taler protocol is heavily based on ideas from
Chaum~\cite{chaum1983blind} and also follows Chaum's basic architecture of Chaum~\cite{chaum1983blind} and also follows Chaum's basic architecture of
customer, merchant and mint (Figure~\ref{fig:cmm}). The two designs customer, merchant and mint (Figure~\ref{fig:cmm}). The two designs
share the key first step where the {\em customer} withdraws digital share the key first step where the {\em customer} withdraws digital
{\em coins} from the {\em mint} with unlinkability provided via blind {\em coins} from the {\em mint} with unlinkability provided via blind
signatures. The coins can then be spend at a {\em merchant} who {\em signatures. The coins can then be spent at a {\em merchant} who {\em
deposits} them at the mint. Taler uses online detection of deposits} them at the mint. Taler uses online detection of
double-spending, thus assuring the merchant instantly that a double-spending, thus assuring the merchant instantly that a
transaction is valid. transaction is valid.
@ -146,95 +146,93 @@ Taler was designed for use in a modern social-liberal society, which we
believe needs a payment system with the following properties: believe needs a payment system with the following properties:
\begin{description} \begin{description}
\item[Customer Anonymity] It must be impossible for mints, merchants \item[Customer Anonymity]
and even a global active adversary, to trace the spending behavior It must be impossible for mints, merchants and even a global active
of a customer. adversary, to trace the spending behavior of a customer.
\item[Unlinkability] Merchants must not be able to tell if two \item[Unlinkability]
transactions were performed by the same customer. It must be As a strong form of customer anonymity, it must be infeasible to
infeasible to link a set of transactions to the same (anonymous) link a set of transactions to the same (anonymous) customer.
customer. %, even when taking aborted transactions into account. %, even when taking aborted transactions into account.
\item[Taxability] In many current legal systems, it is the \item[Taxability]
responsibility of the merchant to deduct (sales) taxes from In many current legal systems, it is the responsibility of the merchant
purchases made by customers, or to pay (income) taxes for payments to deduct (sales) taxes from purchases made by customers, or to
received for work. pay (income) taxes for payments received for work.
%Taxation is neccessary for the state to %Taxation is necessary for the state to
%provide legitimate social functions, such as education. Thus, a payment %provide legitimate social functions, such as education. Thus, a payment
%system must facilitate sales, income and transaction taxes. %system must facilitate sales, income and transaction taxes.
This specifically means that the state must be able to audit merchants (or This requires that merchants, or anybody receiving electronic transfers,
generally anybody receiving money), and thus the receiver of is easily identifiable, so that the state can ensure that its
electronic cash must be easily identifiable. taxation regime is obeyed.
%non-anonymous, as this would enable tax fraud. \item[Verifiability]
\item[Verifiability] The payment system should try to minimize the The payment system should try to minimize the trust necessary between
trust necessary between the participants. In particular, digital the participants. In particular, digital signatures should be used,
signatures should be used extensively in order to be able to and retained, whenever they would play a role in resolving disputes. % between the involved parties.
resolve disputes between the involved parties. Nevertheless, Nevertheless, customers must never be able to defraud anyone, and
customers must never be able to defraud anyone, and merchants must merchants must at best be able to defraud their customers by not
at best be able to defraud their customers by not delivering delivering on the agreed contract. Neither merchants nor customers
on the agreed contract. Neither merchants nor customers must ever should ever be able to commit fraud against the mint. Additionally,
be able to commit fraud against the mint. Both customers and both customers and merchants must receive cryptographic proofs of
merchants must receive cryptographic proofs of bad behavior in bad behavior in case of protocol violations by the mint.
case of protocol violations by the mint. Thus, only the mint will In this way, only the mint will need to be tightly audited and regulated.
have to be tightly audited and regulated. The design must make it The design must make it easy to audit the finances of the mint.
easy to audit the finances of the mint.
\item[Ease of Deployment] %The system should be easy to deploy for \item[Ease of Deployment] %The system should be easy to deploy for
% real-world applications. In order to lower the entry barrier and % real-world applications. In order to lower the entry barrier and
% acceptance of the system, a gateway to the existing financial % acceptance of the system, a gateway to the existing financial
% system should be provided, i.e. by integrating internet-banking % system should be provided, i.e. by integrating internet-banking
% protocols such as HBCI/FinTAN. % protocols such as HBCI/FinTAN.
The digital currency should be The digital coins should be denominated in existing currencies,
tied 1:1 to existing currencies (such as EUR or USD) to avoid such as EUR or USD, to avoid exposing citizens to unnecessary risks
exposing citizens to unnecessary risks from currency fluctuations. from currency fluctuations.
Moreover, the system must have a free software reference Moreover, the system must have an open protocol specification and
implementation and an open protocol standard. a free software reference implementation.
% The protocol should % The protocol should
% be able to run easily over HTTP(S). % be able to run easily over HTTP(S).
\item[Low resource consumption] In order to minimize the operating \item[Low resource consumption]
costs and environmental impact of the payment system, it must In order to minimize the operating costs and environmental impact of
avoid the reliance on expensive and ``wasteful'' computations the payment system, it should avoid the reliance on expensive or
such as proof-of-work. ``wasteful'' computations, such as proof-of-work.
\item[Fractional payments] The payment system needs to handle both \item[Fractional payments]
small and large payments in an efficient and reliable manner. The payment system needs to handle both small and large payments in
Thus, coins cannot just be issued in the smallest unit of currency, an efficient and reliable manner. It is inefficient to simply issue
and a mechanism to give {\em change} must be provided to ensure coins in the smallest unit of currency, so instead a mechanism to
that customers with sufficient total funds can always spend them. give {\em change} should be provided to ensure that customers with
For example, a customer may want to pay \EUR{49,99} using a sufficient total funds can always spend them.
\EUR{100,00} coin. The system must then support giving change in
the form of say two fresh \EUR{0,01} and \EUR{50,00} coins. Those
coins must be {\em unlinkable}: an adversary should not be able to
relate transactions with either of the new coins to the original
\EUR{100,00} coin or transaction or the other change being generated.
\end{description} \end{description}
%
We give a concise example of how these properties interact:
A customer may want to pay \EUR{49,99} using a \EUR{100,00} coin.
the system must thus support giving change in the form of spendable coins,
say a \EUR{0,01} coin and a \EUR{50,00} coin.
A merchant cannot simply give the customer their coins in another transaction
however, as this reverses the role of merchant and customer, and
our taxability requirement would deanonymize the customer.
Instead, the customer should obtain new freshly anonymized coins that cannot be
linked with this transaction, the original \EUR{100,00} coin, or each other.
Instead of using cryptographic methods like $k$-show Instead of using cryptographic methods like $k$-show signatures
signatures to achieve divisiblity~\cite{brands1993efficient}, \cite{brands1993efficient} to achieve divisibility,
Taler's fractional payments use a Taler's fractional payments use a simpler, more powerful mechanism.
simpler, more powerful mechanism. In Taler, a coin is not simply a In Taler, a coin is not simply a unique random token, but a private key.
unique random token, but a private key. Thus, the transfer of a coin A customer transfers currency from a coin to a merchant by cryptographically
can be performed by signing a message using this private key. Thus, signing a deposit message with this private key. This deposit message
the customer can simply specify the fraction of a coin's value that is specifies the fraction of the coin's value to be paid to the merchant.
to be paid to the merchant in the cryptographically signed deposit A key contribution of Taler is the {\em refresh} protocol, which enables
message given to the merchant. A key contribution of Taler is the a customer to exchange the residual value of the exchanged coin for
{\em refresh} protocol, which enables a customer to exchange the unlinkable fleshy anonymized change.
residual value of a coin for fresh coins, thereby providing unlinkable
change. Using online checks, the mint can trivially ensure that all
transactions involving the same coin do not exceed the total value of
the coin.
Online fraud detection can create problems if the network fails during Taler mints ensure that all transactions involving the same coin
the initial steps of a transaction. For example, a law enforcement do not exceed the total value of the coin, thereby
agency might try to entrap a customer by offering illicit goods and requiring that merchants process transactions online.
then cancelling the transaction (i.e. by pretending that there is This improves dramatically on systems that support offline merchants with
a network failure) after learning the public key of the cryptographic threats to deanonymizing customers who double-spend, like
coin. This is equivalent to a benign merchant giving a dissatisfied restrictive blind signatures \cite{brands1993efficient}.
(anonymous) customer a {\em refund} by sending a message affirming In such schemes, if a transaction is interrupted, then any coins sent to
the cancellation. the merchant become tainted, but may never arrive or be spent.
It becomes tricky to extract the value of the tainted coins without linking
If the customer later spends the refunded coin on a purchase with to the aborted transaction and risking deanonymization.
shipping, the state can link the two transactions and might be able to As with support for fractional payments, Taler addresses these problems by
use the shipping address to deanonymize the customer. As with support allowing customers to refresh tainted coins, thereby destroying the link
for fractional payments, Taler addresses this problem by allowing between the refunded or aborted transaction and the coin.
customers to refresh coins, thereby destroying the link between the
refunded (or aborted) transaction and the coin.
Taler ensures that the {\em entity} of the user owning the new coin is Taler ensures that the {\em entity} of the user owning the new coin is
the same as the entity of the user owning the old coin, thus making the same as the entity of the user owning the old coin, thus making
@ -255,29 +253,30 @@ transactions are recorded for eternity, which can enable
identification of users. In theory, this concern has been addressed identification of users. In theory, this concern has been addressed
with the Zerocoin extension to the protocol~\cite{miers2013zerocoin}. with the Zerocoin extension to the protocol~\cite{miers2013zerocoin}.
While these protocols dispense with the need for a central, trusted These protocols do dispense with the need for a central, trusted
authority and provide anonymity, we argue there are some major, authority, while providing a useful measure of pseudonymity.
irredeemable problems inherent in these systems: Yet, there are several major irredeemable problems inherent in their designs:
\begin{itemize} \begin{itemize}
\item Bitcoins are not (easily) taxable. The legality and legitimacy of
this aspect is questionable. The Zerocoin extension would only make
this worse.
\item Bitcoins can not be bound to any fiat currency, and are subject to
significant value fluctuations. While such fluctuations may be
acceptable for high-risk investments, they make Bitcoin unsuitable as
a medium of exchange.
\item The computational puzzles solved by Bitcoin nodes with the purpose \item The computational puzzles solved by Bitcoin nodes with the purpose
of securing the block chain of securing the block chain consume a considerable amount of computational
consume a considerable amount of computational resources and thus resources and energy. So Bitcoin does not an environmentally responsible
energy. Thus, Bitcoin does not represent an environmentally responsible
design. design.
\item Anyone can easily start an alternative Bitcoin transaction chain \item Bitcoin transactions are not easily taxable, leading to legal hurdles.
(a so-called AltCoin) and, if successful, reap the benefits of the low % The legality and legitimacy of this aspect is questionable.
cost to initially create coins via computation. As a result, dozens of The Zerocoin extension would only make this worse.
AltCoins have been created, often without any significant changes to the \item Bitcoins can not easily be bound to any fiat currency, leading to
technology. A large number of AltCoins creates additional overheads for significant fluctuations in value. These fluctuations may be desirable in
currency exchange and exascerbates the problems with currency fluctuations. a high-risk investment instrument, but they make Bitcoin unsuitable as
a medium of exchange.
\item Worse, 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 via computation. As participants are
de facto investors, these 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} \end{itemize}
GreenCoinX\footnote{\url{https://www.greencoinx.com/}} is a more GreenCoinX\footnote{\url{https://www.greencoinx.com/}} is a more
@ -293,16 +292,15 @@ systems.
\subsection{Chaum-style electronic cash} \subsection{Chaum-style electronic cash}
Taler builds on ideas from Chaum~\cite{chaum1983blind}, who proposed a Taler builds on ideas from Chaum~\cite{chaum1983blind}, who proposed a
digital payment system that would provide (some) customer anonymity digital payment system that would provide some customer anonymity
while disclosing the identity of the merchants. Chaum's digital cash while disclosing the identity of the merchants. Chaum's digital cash
(DigiCash) system had some limitations and ultimately failed to be widely system DigiCash had some limitations and ultimately failed to be widely
adopted. In our assessment, key reasons for DigiCash's failure that adopted. In our assessment, key reasons for DigiCash's failure that
Taler avoids include: Taler avoids include:
\begin{itemize} \begin{itemize}
\item The use of patents to protect the technology; a payment system \item The use of patents to protect the technology; a payment system
must be libre --- free software --- to have a chance for widespread should be free software (libre) to have a chance for widespread adoption.
adoption.
\item The use of off-line payments and thus deferred detection of \item The use of off-line payments and thus deferred detection of
double-spending, which could require the mint to attempt to recover double-spending, which could require the mint to attempt to recover
funds from customers via the legal system. This creates a funds from customers via the legal system. This creates a
@ -311,7 +309,7 @@ Taler avoids include:
payments might have been a necessary feature. However, today payments might have been a necessary feature. However, today
requiring network connectivity is feasible and avoids the business requiring network connectivity is feasible and avoids the business
risks associated with deferred fraud detection. risks associated with deferred fraud detection.
\item % In addition to the risk of legal disputes with fradulent \item % In addition to the risk of legal disputes with fraudulent
% merchants and customers, % merchants and customers,
Chaum's published design does not clearly Chaum's published design does not clearly
limit the financial damage a mint might suffer from the limit the financial damage a mint might suffer from the
@ -331,7 +329,7 @@ Taler avoids include:
Chaum's original digital cash system~\cite{chaum1983blind} was Chaum's original digital cash system~\cite{chaum1983blind} was
extended by Brands~\cite{brands1993efficient} with the ability to {\em extended by Brands~\cite{brands1993efficient} with the ability to {\em
divide} coins and thus spend (certain) fractions of a coin using divide} coins and thus spend certain fractions of a coin using
restrictive blind signatures. Compared to Taler, performing restrictive blind signatures. Compared to Taler, performing
fractional payments is cryptographically way more expensive and fractional payments is cryptographically way more expensive and
moreover the transactions performed with ``divisions'' from the same moreover the transactions performed with ``divisions'' from the same
@ -359,13 +357,12 @@ the mint. Instead of always paying, the customer ``gambles'' with the
merchant for each microdonation. Only if the merchant wins, the merchant for each microdonation. Only if the merchant wins, the
microdonation is upgraded to a macropayment to be deposited at the microdonation is upgraded to a macropayment to be deposited at the
mint. Peppercoin does not provide customer-anonymity. The proposed mint. Peppercoin does not provide customer-anonymity. The proposed
statistical method for mints detecting fraudulent cooperation between statistical method by which mints detect fraudulent cooperation between
customers and merchants at the expense of the mint not only creates customers and merchants at the expense of the mint not only creates
legal risks for the mint (who has to make a statistical argument), but legal risks for the mint, but would also require that the mint learns
also would require the mint to learn about microdonations where the about microdonations where the merchant did not get upgraded to a
merchant did not get upgraded to a macropayment. Thus, it is unclear macropayment. It is therefore unclear how Peppercoin would actually
how Peppercoin would actually reduce the computational burden on the reduce the computational burden on the mint.
mint.
\section{Design} \section{Design}
@ -424,7 +421,7 @@ from customers using legal means.
Electronic coins are trivially copied between machines. Thus, we must Electronic coins are trivially copied between machines. Thus, we must
clarify what kinds of operations can even be expected to be taxed. clarify what kinds of operations can even be expected to be taxed.
After all, without instrusive measures to take away control of the After all, without intrusive measures to take away control of the
computing platform from its users, copying an electronic wallet from computing platform from its users, copying an electronic wallet from
one computer to another can hardly be prevented by a payment system. one computer to another can hardly be prevented by a payment system.
Furthermore, it would also hardly be appropriate to tax the moving of Furthermore, it would also hardly be appropriate to tax the moving of
@ -625,7 +622,7 @@ fresh coin.
%As with other operations, the refreshing protocol must also protect %As with other operations, the refreshing protocol must also protect
%the mint from double-spending; similarly, the customer has to have %the mint from double-spending; similarly, the customer has to have
%cryptographic evidence if there is any misbehaviour by the mint. %cryptographic evidence if there is any misbehavior by the mint.
%Finally, the mint may choose to charge a transaction fee for %Finally, the mint may choose to charge a transaction fee for
%refreshing by reducing the value of the generated fresh coins %refreshing by reducing the value of the generated fresh coins
%in relation to the value of the melted coins. %in relation to the value of the melted coins.
@ -657,7 +654,7 @@ because it is certified by the auditors.
As we are dealing with financial transactions, we explicitly describe As we are dealing with financial transactions, we explicitly describe
whenever entities need to safely commit data to persistent storage. whenever entities need to safely commit data to persistent storage.
As long as those commitments persist, the protocol can be safely As long as those commitments persist, the protocol can be safely
resumed at any step. Commitments to disk are cummulative, that is an resumed at any step. Commitments to disk are cumulative, that is an
additional commitment does not erase the previously committed additional commitment does not erase the previously committed
information. Keys and thus coins always have a well-known expiration information. Keys and thus coins always have a well-known expiration
date; information committed to disk can be discarded after the date; information committed to disk can be discarded after the
@ -729,7 +726,7 @@ $\widetilde{C} := S_K(C_p)$:
transaction, $a$ is data relevant to the contract indicating which services 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, 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 and $p$ is the merchant's payment information (e.g. his IBAN number) and $r$ is
a random nounce. The merchant commits $\langle \mathcal{A} a random nonce. The merchant commits $\langle \mathcal{A}
\rangle$ to disk and sends $\mathcal{A}$ to the customer. \rangle$ to disk and sends $\mathcal{A}$ to the customer.
\item\label{deposit} The customer must possess or acquire a coin minted by a mint that is \item\label{deposit} The customer must possess or acquire a coin minted by a mint that is
accepted by the merchant, i.e. $K$ should be publicly signed by some $D_j accepted by the merchant, i.e. $K$ should be publicly signed by some $D_j
@ -947,7 +944,7 @@ the certification process.
The refresh protocol offers an easy way to enable refunds to The refresh protocol offers an easy way to enable refunds to
customers, even if they are anonymous. Refunds can be supported customers, even if they are anonymous. Refunds can be supported
by including a public signing key of the mechant in the transaction by including a public signing key of the merchant in the transaction
details, and having the customer keep the private key of the spent details, and having the customer keep the private key of the spent
coins on file. coins on file.
@ -982,7 +979,7 @@ check and not also all previous owners of the physical check.
As with any unconditionally anonymous payment system, the ``Perfect As with any unconditionally anonymous payment system, the ``Perfect
Crime'' attack~\cite{solms1992perfect} where blackmail is used to Crime'' attack~\cite{solms1992perfect} where blackmail is used to
force the mint to issue anonymous coins also continues to apply in force the mint to issue anonymous coins also continues to apply in
principle. However, as mentioned Taler does faciliate limits on principle. However, as mentioned Taler does facilitate limits on
withdrawals, which we believe is a better trade-off than the withdrawals, which we believe is a better trade-off than the
problematic escrow systems where the necessary intransparency problematic escrow systems where the necessary intransparency
actually facilitates voluntary cooperation between the mint and actually facilitates voluntary cooperation between the mint and
@ -1033,7 +1030,7 @@ in courts. Taler's implementation is designed to export evidence and
upholds the core principles described in~\cite{fc2014murdoch}. In upholds the core principles described in~\cite{fc2014murdoch}. In
particular, in providing the cryptographic proofs as evidence none of particular, in providing the cryptographic proofs as evidence none of
the participants have to disclose their core secrets, the process is the participants have to disclose their core secrets, the process is
covered by standard testing proceedures, and the full trusted covered by standard testing procedures, and the full trusted
computing base (TCB) is public and free software. computing base (TCB) is public and free software.
%\subsection{System Performance} %\subsection{System Performance}
@ -1292,7 +1289,7 @@ 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 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 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 flip, and at this point the merchant might not be able to recover from
the loss. A fradulent anonymous customer may run the protocol using the loss. A fraudulent anonymous customer may run the protocol using
already spent coins until the coin flip is in his favor. already spent coins until the coin flip is in his favor.
As with incremental spending, lock permissions could be used to ensure As with incremental spending, lock permissions could be used to ensure
@ -1327,7 +1324,7 @@ The following steps are executed for microdonations with upgrade probability $p$
\end{enumerate} \end{enumerate}
Evidently the customer can ``cheat'' by aborting the transaction in Evidently the customer can ``cheat'' by aborting the transaction in
Step 3 of the microdonation protocol if the outcome is unfavourable --- Step 3 of the microdonation protocol if the outcome is unfavorable ---
and repeat until he wins. This is why Taler is suitable for and repeat until he wins. This is why Taler is suitable for
microdonations --- where the customer voluntarily contributes --- microdonations --- where the customer voluntarily contributes ---
and not for micropayments. and not for micropayments.