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

update Fig 1, add section on error handling, expand on importance/role of linkage protocol, mention performance measurements, Acks

Browse Source
This commit is contained in:
Christian Grothoff 2015-09-06 18:35:24 +02:00
parent a5f6cbd920
commit 92902cb958
1 changed files with 101 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

108
doc/paper/taler.tex
View File

@ -191,18 +191,20 @@ his message to the merchant.
\begin{figure}[h]
\centering
\begin{tikzpicture}
\tikzstyle{def} = [node distance= 7em and 10em, inner sep=1em, outer sep=.3em];
\tikzstyle{def} = [node distance= 5em and 7em, inner sep=1em, outer sep=.3em];
\node (origin) at (0,0) {};
\node (mint) [def,above=of origin,draw]{Mint};
\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) -- (mint) node [midway, above, sloped] (TextNode) {withdraw coins};
\draw [<-, C] (mint) -- (merchant) node [midway, above, sloped] (TextNode) {deposit coins};
\draw [<-, C] (merchant) -- (customer) node [midway, above, sloped] (TextNode) {spend coins};
\draw [<-, C] (mint) -- (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}
@ -776,13 +778,78 @@ and $G$ is the generator of the elliptic curve.
\subsection{Linking}
% FIXME: explain better...
For a coin that was successfully refreshed, the mint responds to
a request $S_{C'}(\mathtt{link})$ with $(T^{(\gamma)}_p$, $E_{\gamma}, \widetilde{C})$.
For a coin that was successfully refreshed, the mint responds to a
request $S_{C'}(\mathtt{link})$ with $(T^{(\gamma)}_p$, $E_{\gamma},
\widetilde{C})$.
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.
executed by another party who learned $C'_s$ from the old owner. As a
result, linking ensures that access to the new coins minted by 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 mint 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 Bob from abusing the refresh protocol to evade taxation on
transactions.
The auditor can anonymously check if the mint correctly implements the
link request, thus preventing the mint 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 with the developer.
The second case is a faulty mint service provider. Such faults will
be detected because of protocol violations (for example, by providing
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 provider.
The third case are transient failures, such as network failures or
temporary hardware failures at the mint 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, 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, for example by shutting
down the operator (while providing an opportunity for customers to
receive refunds for the coins in circulation). 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.
\section{Discussion}
@ -840,15 +907,15 @@ transfer.
%suitable for money laundering, we are optimistic that states will find
%the design desirable.
We did not yet perform performance measurements for the various
operations. However, we are pretty sure that the computational and
bandwidth cost for transactions described in this paper is likely
small compared to other business costs for the mint. We expect costs
within the system to be dominated by the (replicated, transactional)
database. However, these expenses are again likely small in relation
to the business cost of currency transfers using traditional banking.
Here, mint operators should be able to reduce their expenses by
aggregating multiple transfers to the same merchant.
We performed some initial performance measurements for the various
operations. 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 mint. However, this figure excludes the cost
of currency transfers using traditional banking, which a mint operator
would ultimately have to interact with. Here, mint operators should
be able to reduce their expenses by aggregating multiple transfers to
the same merchant.
\section{Conclusion}
@ -862,6 +929,15 @@ protocol may finally enable modern society to upgrade to proper
electronic wallets with efficient, secure and privacy-preserving
transactions.
\subsection*{Acknowledgements}
This work was supported by a grant from the Renewable Freedom Foundation.
% FIXME: ARED?
We thank Tanja Lange and Dan Bernstein 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}