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

edits

Browse Source
This commit is contained in:
Christian Grothoff 2015-09-09 20:33:34 +02:00
parent a5f6cbd920
commit 015cf82019
1 changed files with 99 additions and 87 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

186
doc/paper/taler.tex
View File

@ -18,9 +18,9 @@
% 'transaction' already when we talk about taxable % 'transaction' already when we talk about taxable
% transfers of Taler coins and database 'transactions'. % transfers of Taler coins and database 'transactions'.
% - wallet = coins at customer % - wallet = coins at customer
% - reserve = currency entrusted to mint waiting for withdrawl % - reserve = currency entrusted to mint waiting for withdrawal
% - deposit = SEPA to mint % - deposit = SEPA to mint
% - withdrawl = mint to customer % - withdrawal = mint to customer
% - spending = customer to merchant % - spending = customer to merchant
% - redeeming = merchant to mint (and then mint SEPA to merchant) % - redeeming = merchant to mint (and then mint SEPA to merchant)
% - refreshing = customer-mint-customer % - refreshing = customer-mint-customer
@ -403,11 +403,11 @@ information leakage is outside of the scope of this work.
The customer may use an anonymous communication channel for the The customer may use an anonymous communication channel for the
communication with the mint to avoid leaking IP address information; communication with the mint to avoid leaking IP address information;
however, the mint will anyway be able to determine the customer's however, the mint will anyway be able to determine the customer's
identity from the (SEPA) transfer that the customer initiates to identity from the wire transfer or some other authentication process
obtain anonymous digital cash. The scheme is anonymous that the customer initiates to withdraw anonymous digital cash. The
because the mint will be unable to link the known identity of the scheme is anonymous because the mint will be unable to link the known
customer that withdrew anonymous digital currency to the {\em identity of the customer that withdrew anonymous digital currency to
purchase} performed later at the merchant. the {\em purchase} performed later at the merchant.
% All the mint will be % All the mint will be
%able to confirm is that the customer is {\em one} of its patrons who %able to confirm is that the customer is {\em one} of its patrons who
%previously obtained the anonymous digital currency --- and of course %previously obtained the anonymous digital currency --- and of course
@ -466,17 +466,22 @@ private {\em master signing key} of the mint and possibly the auditor.
Before a customer can withdraw a coin from the mint, he has to pay the Before a customer can withdraw a coin from the mint, he has to pay the
mint the value of the coin, as well as processing fees. This is done mint the value of the coin, as well as processing fees. This is done
using other means of payments, such as SEPA transfers~\cite{sepa}. using other means of payments, such as wire transfers~\cite{sepa} or
The subject line of the transfer must contain {\em withdrawal by having a personal {\em reserve} at the mint (which is equivalent to
authorization key}, a public key for digital signatures generated by a bank account with a positive balance). Taler assumes that the
the customer. When the mint receives a transfer with a public key in customer has a {\em withdrawal authorization key} to identify himself
the subject, it adds the funds to a {\em reserve} identified by the as authorized to withdraw funds from the reserved. By signing the
withdrawl authorization key. By signing the withdrawl messages using withdrawal request messages using the withdrawal authorization key,
the withdrawl authorization key, the customer can prove to the mint the customer can prove to the mint that he is the individual
that he is authorized to withdraw anonymous digital coins from the authorized to withdraw anonymous digital coins from the reserve. The
reserve. The mint will record the withdrawl messages with the reserve mint will record the withdrawal messages with the reserve record as
record as proof that the anonymous digital coin was created for the proof that the anonymous digital coin was created for the correct
correct customer. customer. We note that the specifics of how the customer
authenticates to the mint are orthogonal to the rest of the system,
and multiple methods can be supported. 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 minted, the customer is the only entity that knows the After a coin is minted, the customer is the only entity that knows the
private key of the coin, making him the \emph{owner} of the coin. The private key of the coin, making him the \emph{owner} of the coin. The
@ -495,16 +500,11 @@ private key. A merchant can then transfer this permission of the
coin's owner to the mint to obtain the amount in traditional currency. coin's owner to the mint to obtain the amount in traditional currency.
If the customer is cheating and the coin was already spent, the mint If the customer is cheating and the coin was already spent, the mint
provides cryptographic proof of the fraud to the merchant, who will provides cryptographic proof of the fraud to the merchant, who will
then refuse the transaction. then refuse the transaction. The mint is typically expected to
% The mint is typically expected transfer the funds to the merchant using a wire transfer or by
%to transfer the funds to the merchant using a SEPA transfer or similar crediting the merchant's individual account, depending on what is
%methods appropriate to the domain of the traditional currency. appropriate to the domain of the traditional currency.
%The mint needs to ensure that a coin can only be spent once. This is
%done by storing the public keys of all deposited coins (together with
%the deposit request and the owner's signature confirming the
%transaction). The mint's state can be limited as coins signed with
%expired coin sigining keys do not have to be retained.
\paragraph{Partial spending.} \paragraph{Partial spending.}
@ -514,13 +514,13 @@ spending of coins. Consequently, the mint the must not only store the
identifiers of spent coins, but also the fraction of the coin that has identifiers of spent coins, but also the fraction of the coin that has
been spent. been spent.
%\paragraph{Online checks.} \paragraph{Online checks.}
%
%For secure transactions (non-microdonations), the merchant is expected For secure transactions, the merchant is expected to perform an online
%to perform an online check to detect double-spending. In the simplest check to detect double-spending. Thus, the merchant must deposit the
%case, the merchant simply directly confirms the validity of the coin with the mint (and validate the signature from the mint
%deposit permission signed by the coin's owner with the mint, and then confirming the validity of the transaction) before proceeding with its
%proceeds with the contract. business logic.
\subsection{Refreshing Coins} \subsection{Refreshing Coins}
@ -569,13 +569,14 @@ in relation to the value of the melted coins.
% In this section, we describe the protocols for Taler in detail. % In this section, we describe the protocols for Taler in detail.
For the sake of brevity, we do not specifically state that the For the sake of brevity, we assume that a recipient of a signed
recipient of a signed message always first checks that the signature message always first checks that the signature is valid, even though
is valid. Also, whenever a signed message is transmitted, it is this is not explicitly stated below. Also, whenever a signed message
assumed that the receiver is told the public key (or knows it from the is transmitted, it is assumed that the receiver is told the public key
context) and that the signature contains additional identification as (or knows it from the context) and that the signature contains
to the purpose of the signature (such that it is not possible to additional identification as to the purpose of the signature (such
use a signature from one protocol step in a different context). that it is not possible to use a signature from one protocol step in a
different context).
When the mint signs messages (not coins), an {\em online message When the mint signs messages (not coins), an {\em online message
signing key} of the mint is used. The mint's long-term offline key signing key} of the mint is used. The mint's long-term offline key
@ -584,7 +585,7 @@ message signing key of the mint. The mint's long-term offline key is
assumed to be well-known to both customers and merchants, for example assumed to be well-known to both customers and merchants, for example
because it is certified by the auditors. because it is certified by the auditors.
As we are dealing with financial transactions, we explicitly state 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 cummulative, that is an
@ -665,7 +666,7 @@ $\widetilde{C} := S_K(C_p)$:
assume that one coin is sufficient.) assume that one coin is sufficient.)
The customer then generates a \emph{deposit-permission} $\mathcal{D} := The customer then generates a \emph{deposit-permission} $\mathcal{D} :=
S_c(\widetilde{C}, m, f, H(a), H(p,r), M_p)$ S_c(\widetilde{C}, m, f, H(a), H(p,r), M_p)$
and sends $\langle \mathcal{D}, D_i\rangle$ to the merchant, and sends $\langle \mathcal{D}, D_i\rangle$ to the merchant,
where $D_i$ is the mint which signed $K$. where $D_i$ is the mint which signed $K$.
\item The merchant gives $(\mathcal{D}, p, r)$ to the mint, revealing his \item The merchant gives $(\mathcal{D}, p, r)$ to the mint, revealing his
@ -722,7 +723,7 @@ execute the coin refreshing protocol with the mint.
%\end{figure} %\end{figure}
\subsection{Refreshing} \subsection{Refreshing} \label{sec:refreshing}
The following protocol is executed in order to refresh a coin $C'$ of The following protocol is executed in order to refresh a coin $C'$ of
denomination $K$ to a fresh coin $\widetilde{C}$ with the same denomination $K$ to a fresh coin $\widetilde{C}$ with the same
@ -784,40 +785,48 @@ This allows the owner of the old coin to also obtain the private key
of the new coin, even if the refreshing protocol was illicitly of the new coin, even if the refreshing protocol was illicitly
executed by another party who learned $C'_s$ from the old owner. executed by another party who learned $C'_s$ from the old owner.
\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 mechant 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 mint (and the customer). Assuming the mint has
a way to recover the funds from the merchant (or simply not performed
the wire transfer yet), the mint 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.
The (anonymous) customer -- but nobody else -- can then use the
refresh protocol to melt the refunded coin and create a fresh coin
that is unlinkable to the refunded transaction.
\section{Discussion} \section{Discussion}
\subsection{Offline Payments} \subsection{Offline Payments}
Chaum's original proposals for anonymous digital cash avoided the Chaum's original proposals for anonymous digital cash avoided the need
locking and online spending steps detailed in this proposal by for online interactions with the mint to detect double spending by
providing a means to deanonymize customers involved in providing a means to deanonymize customers involved in
double-spending. We believe that this is problematic as the mint or double-spending. We believe that this is problematic as the mint or
the merchant will then still need out-of-band means to recover funds the merchant will then still need out-of-band means to recover funds
from the customer, which may be impossible in practice. In contrast, from the customer, which may be impossible in practice. In contrast,
in our design only the mint may try to defraud the other participants in our design only the mint may try to defraud the other participants
and disappear. While this is still a risk, this is likely manageable, and disappear. While this is still a risk, and regular financial
especially compared to recovering funds via the court system from audits are required to protect against it, this is more manageable and
customers. significantly cheaper compared to recovering funds via the court
system from customers.
Chaum's method for offline payments would also be incompatible with
\subsection{Bona-fide microdonations} the refreshing protocol (Section~\ref{sec:refreshing}) which enables
the crucial feature of giving unlinkable change. The reason is that
Evidently the customer can ``cheat'' by aborting the transaction in if the owner's identity were embedded in coins, it would be leaked to
Step 3 of the microdonation protocol if the outcome is unfavourable --- the mint as part of the reveal operation in the cut-and-choose
and repeat until he wins. This is why Taler is suitable for operation of the refreshing protocol.
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.
\subsection{Merchant Tax Audits} \subsection{Merchant Tax Audits}
@ -872,25 +881,12 @@ transactions.
In this appendix we detail various optional features that can In this appendix we detail various optional features that can
be added to the basic protocol. be added to the basic protocol.
\subsection{Refunds} However, we note that Taler's transaction costs are expected to be so
low that these features are not particularly useful, as they are about
The refresh protocol offers an easy way to enable refunds to reducing interactions with the mint to reduce costs. In particular,
customers, even if they are anonymous. Refunds can be supported we expect that transactions with amounts below Taler's transaction
by including a public signing key of the mechant in the transaction costs to be economically meaningless. Nevertheless, we document
details, and having the customer keep the private key of the spent various ways how this could be achieved.
coins on file.
Given this, the merchant can simply sign a {\em refund confirmation}
and share it with the mint (and the customer). Assuming the mint has
a way to recover the funds from the merchant (or simply not performed
the transfer yet), the mint 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.
The (anonymous) customer -- but nobody else -- can then use the
refresh protocol to melt the refunded coin and create a fresh coin
that is unlinkable to the previous transaction.
\subsection{Incremental spending} \subsection{Incremental spending}
@ -1079,7 +1075,7 @@ 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 fradulent 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
that the customer cannot defraud the merchant by offering a coin that that the customer cannot defraud the merchant by offering a coin that
@ -1112,4 +1108,20 @@ The following steps are executed for microdonations with upgrade probability $p$
with $H(r_c)$. with $H(r_c)$.
\end{enumerate} \end{enumerate}
Evidently the customer can ``cheat'' by aborting the transaction in
Step 3 of the microdonation protocol if the outcome is unfavourable ---
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.
\end{document} \end{document}