edits

1 files changed, 99 insertions, 22 deletions

diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index a728471c0..e3fb83592 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -191,18 +191,20 @@ his message to the merchant.
 \begin{figure}[h]
 \centering
 \begin{tikzpicture}
+ \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]
 
-\tikzstyle{def} = [node distance= 7em and 10em, 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};
+ \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};
 
-\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};
 \end{tikzpicture}
 \caption{Taler's system model for the payment system is based on Chaum~\cite{chaum1983blind}.}
 \label{fig:cmm}
@@ -777,13 +779,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.
 
 \subsection{Refunds}
 
@@ -849,15 +916,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}
@@ -871,6 +938,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}
 
@@ -888,6 +964,7 @@ 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}
 
 For services that include pay-as-you-go billing, customers can over