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

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];
-
-\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};
+ \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
-For a coin that was successfully refreshed, the mint responds to
+request $S_{C'}(\mathtt{link})$ with $(T^{(\gamma)}_p$, $E_{\gamma},
-a request $S_{C'}(\mathtt{link})$ with $(T^{(\gamma)}_p$, $E_{\gamma}, \widetilde{C})$.
+\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
+We performed some initial performance measurements for the various
-operations.  However, we are pretty sure that the computational and
+operations.  The main conclusion was that the computational and
-bandwidth cost for transactions described in this paper is likely
+bandwidth cost for transactions described in this paper is smaller
-small compared to other business costs for the mint.  We expect costs
+than $10^{-3}$ cent/transaction, and thus dwarfed by the other
-within the system to be dominated by the (replicated, transactional)
+business costs for the mint.  However, this figure excludes the cost
-database.  However, these expenses are again likely small in relation
+of currency transfers using traditional banking, which a mint operator
-to the business cost of currency transfers using traditional banking.
+would ultimately have to interact with.  Here, mint operators should
-Here, mint operators should be able to reduce their expenses by
+be able to reduce their expenses by aggregating multiple transfers to
-aggregating multiple transfers to the same merchant.
+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}