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
% transfers of Taler coins and database 'transactions'.
% - wallet = coins at customer
% - reserve = currency entrusted to mint waiting for withdrawl
% - reserve = currency entrusted to mint waiting for withdrawal
% - deposit = SEPA to mint
% - withdrawl = mint to customer
% - withdrawal = mint to customer
% - spending = customer to merchant
% - redeeming = merchant to mint (and then mint SEPA to merchant)
% - 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
communication with the mint to avoid leaking IP address information;
however, the mint will anyway be able to determine the customer's
identity from the (SEPA) transfer that the customer initiates to
obtain anonymous digital cash. The scheme is anonymous
because the mint will be unable to link the known identity of the
customer that withdrew anonymous digital currency to the {\em
purchase} performed later at the merchant.
identity from the wire transfer or some other authentication process
that the customer initiates to withdraw anonymous digital cash. The
scheme is anonymous because the mint will be unable to link the known
identity of the customer that withdrew anonymous digital currency to
the {\em purchase} performed later at the merchant.
% All the mint will be
%able to confirm is that the customer is {\em one} of its patrons who
%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
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}.
The subject line of the transfer must contain {\em withdrawal
authorization key}, a public key for digital signatures generated by
the customer. When the mint receives a transfer with a public key in
the subject, it adds the funds to a {\em reserve} identified by the
withdrawl authorization key. By signing the withdrawl messages using
the withdrawl authorization key, the customer can prove to the mint
that he is authorized to withdraw anonymous digital coins from the
reserve. The mint will record the withdrawl messages with the reserve
record as proof that the anonymous digital coin was created for the
correct customer.
using other means of payments, such as wire transfers~\cite{sepa} or
by having a personal {\em reserve} at the mint (which is equivalent to
a bank account with a positive balance). Taler assumes that the
customer has a {\em withdrawal authorization key} to identify himself
as authorized to withdraw funds from the reserved. By signing the
withdrawal request messages using the withdrawal authorization key,
the customer can prove to the mint that he is the individual
authorized to withdraw anonymous digital coins from the reserve. The
mint will record the withdrawal messages with the reserve record as
proof that the anonymous digital coin was created for the correct
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
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.
If the customer is cheating and the coin was already spent, the mint
provides cryptographic proof of the fraud to the merchant, who will
then refuse the transaction.
% The mint is typically expected
%to transfer the funds to the merchant using a SEPA transfer or similar
%methods appropriate to the domain of the traditional currency.
then refuse the transaction. The mint is typically expected to
transfer the funds to the merchant using a wire transfer or by
crediting the merchant's individual account, depending on what is
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.}
@ -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
been spent.
%\paragraph{Online checks.}
%
%For secure transactions (non-microdonations), the merchant is expected
%to perform an online check to detect double-spending. In the simplest
%case, the merchant simply directly confirms the validity of the
%deposit permission signed by the coin's owner with the mint, and then
%proceeds with the contract.
\paragraph{Online checks.}
For secure transactions, the merchant is expected to perform an online
check to detect double-spending. Thus, the merchant must deposit the
coin with the mint (and validate the signature from the mint
confirming the validity of the transaction) before proceeding with its
business logic.
\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.
For the sake of brevity, we do not specifically state that the
recipient of a signed message always first checks that the signature
is valid. Also, whenever a signed message is transmitted, it is
assumed that the receiver is told the public key (or knows it from the
context) and that the signature contains additional identification as
to the purpose of the signature (such that it is not possible to
use a signature from one protocol step in a different context).
For the sake of brevity, we assume that a recipient of a signed
message always first checks that the signature is valid, even though
this is not explicitly stated below. Also, whenever a signed message
is transmitted, it is assumed that the receiver is told the public key
(or knows it from the context) and that the signature contains
additional identification as to the purpose of the signature (such
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
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
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.
As long as those commitments persist, the protocol can be safely
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.)
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,
where $D_i$ is the mint which signed $K$.
\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}
\subsection{Refreshing}
\subsection{Refreshing} \label{sec:refreshing}
The following protocol is executed in order to refresh a coin $C'$ of
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
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}
\subsection{Offline Payments}
Chaum's original proposals for anonymous digital cash avoided the
locking and online spending steps detailed in this proposal by
Chaum's original proposals for anonymous digital cash avoided the need
for online interactions with the mint to detect double spending by
providing a means to deanonymize customers involved in
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
from the customer, which may be impossible in practice. In contrast,
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,
especially compared to recovering funds via the court system from
customers.
and disappear. While this is still a risk, and regular financial
audits are required to protect against it, this is more manageable and
significantly cheaper compared to recovering funds via the court
system from customers.
\subsection{Bona-fide microdonations}
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.
Chaum's method for offline payments would also be incompatible with
the refreshing protocol (Section~\ref{sec:refreshing}) which enables
the crucial feature of giving unlinkable change. The reason is that
if the owner's identity were embedded in coins, it would be leaked to
the mint as part of the reveal operation in the cut-and-choose
operation of the refreshing protocol.
\subsection{Merchant Tax Audits}
@ -872,25 +881,12 @@ transactions.
In this appendix we detail various optional features that can
be added to the basic protocol.
\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 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.
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
reducing interactions with the mint to reduce costs. In particular,
we expect that transactions with amounts below Taler's transaction
costs to be economically meaningless. Nevertheless, we document
various ways how this could be achieved.
\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
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
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
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)$.
\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}