Merge branch 'master' of ssh://taler.net/exchange

1 files changed, 67 insertions, 21 deletions

diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index a8baae3e6..0bfbd87d7 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -871,7 +871,9 @@ with signature $\widetilde{C} := S_K(\FDH_K(C_p))$
   public key.
 \item
   The merchant creates a signed contract
-    $\mathcal{A} := S_M(m, f, a, H(p, r), \vec{X})$
+  \begin{equation*}
+    \mathcal{A} := S_M(m, f, a, H(p, r), \vec{X})
+  \end{equation*}
   where $m$ is an identifier for this transaction, $f$ is the price of the offer,
   and $a$ is data relevant
   to the contract indicating which services or goods the merchant will
@@ -1011,9 +1013,12 @@ than the comparable use of zk-SNARKs in ZeroCash~\cite{zerocash}.
     for $i \in \{1,\ldots,\kappa\}$ and sends a signed commitment
      $S_{C'}(\vec{B}, \vec{T_p})$ to the exchange.
   \item % [200 OK / 409 CONFLICT]
-    The exchange generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and
-    marks $C'_p$ as spent by persisting
-    $\langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$.
+    The exchange checks that $C'_p$ is a valid coin of sufficient balance
+    to cover the value of the fresh coins to be generated and prevent
+    double-spending.  Then,
+    the exchange generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and
+    marks $C'_p$ as spent by persisting the \emph{refresh-record}
+    $\mathcal{F} = \langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$.
     Auditing processes should assure that $\gamma$ is unpredictable until
     this time to prevent the exchange from assisting tax evasion. \\
     %
@@ -1372,47 +1377,67 @@ protocol is never used.
 
 \subsection{Exculpability arguments}
 
-\begin{lemma}
+\begin{lemma}\label{lemma:double-spending}
 The exchange can detect and prove double-spending.
 \end{lemma}
 
 \begin{proof}
+A coin can only be spent by running the deposit protocol or the refresh
+protocol with the exchange.  Thus every time a coin is spent, the exchange
+obtains either a deposit-permission or a refresh-record, both of which
+contain a signature made with the public key of coin to authorizing the
+respective operation.  If the exchange has a set of refresh-records and
+deposit-permissions whose total value exceed the value of the coin, the
+exchange can show this set to prove that a coin was double-spend.
 \end{proof}
 
-\begin{lemma}
-Merchants and customers can verify double-spending proofs.
-\end{lemma}
-
-\begin{proof}
-\end{proof}
-
+\begin{corollary}
+Merchants and customers can verify double-spending proofs by verifying that the
+signatures in the set of refresh-records and deposit-permissions are correct and
+that the total value exceeds the coin's value.
+\end{corollary}
 
 \begin{lemma}
-Customers can either obtain proof-of-payment or their money back.
+% only holds given sufficient time
+Customers can either obtain proof-of-payment or their money back, even
+when the merchant is faulty.
 \end{lemma}
 
 \begin{proof}
+When the customer sends the deposit-permission for a coin
+to a correct merchant, the merchant will pass it on to the
+exchange, and pass the exchange's response, a deposit-confirmation, on
+to the customer.  If a faulty merchant deposits the coin
+but does not pass the deposit-confirmation to the customer,
+the customer will receive the deposit-confirmation as an error
+response from the refreshing protocol.  Otherwise if the merchant
+doesn't deposit the coin, the customer can get a new, unlinkable
+coin by running the refresh protocol.
 \end{proof}
 
-\begin{lemma}
-If a customer paid for a contract, they can prove it.
-\end{lemma}
-
-\begin{proof}
-\end{proof}
+\begin{corollary}
+If a customer paid for a contract, they can prove it by showing
+the deposit permissions for all coins.
+\end{corollary}
 
 \begin{lemma}
 The merchant can issue refunds, and only to the original customer.
 \end{lemma}
 
 \begin{proof}
+Since the refund only increases the balance of a coin that the original
+customer owns, only the original customer can spend the refunded coin again.
 \end{proof}
 
 
-
 \begin{theorem}
   The protocol prevents double-spending and provides exculpability.
 \end{theorem}
+\begin{proof}
+  Follows from Lemma \ref{lemma:double-spending} and the assumption
+  that the exchange can't forge signatures to obtain an incriminating
+  set of deposit-permissions and/or refresh-records.
+\end{proof}
 
 
 
@@ -1580,6 +1605,24 @@ upholds the core principles described in~\cite{fc2014murdoch}.  In
 particular, in providing the cryptographic proofs as evidence none of
 the participants have to disclose their core secrets.
 
+\subsection{Business concerns}
+
+The Taler system implementation includes additional protocol elements
+to address real-world concerns.  To begin with, the exchange
+automatically transfers any funds that have been left for an extended
+amount of time in a customer's reserve back to the customer's bank
+account.  Furthermore, we allow the exchange to revoke denomination
+keys, and wallets periodically check for such revocations.  If a
+denomination key has been revoked, the wallets use the {\em payback}
+protocol to deposit funds back to the customer's reserve, from where
+they are either withdrawn with a new denomination key or sent back to
+the customer's bank account.  Unlike ordinary deposits, the payback
+protocol does not incur any transaction fees. The primary use of the
+protocol is to limit the financial loss in cases where an audit
+reveals that the exchange's private keys were compromised, and to
+automatically pay back balances held in a customers' wallet if an
+exchange ever goes out of business.
+
 
 %\subsection{System Performance}
 %
@@ -1798,7 +1841,10 @@ coin first.
   the exchange persists $\langle \mathcal{L} \rangle$
   and notifies the merchant that locking was successful.
 \item\label{contract2} The merchant creates a digitally signed contract
-  $\mathcal{A} := S_M(m, f, a, H(p, r))$ where $a$ is data relevant to the contract
+  \begin{equation*}
+    \mathcal{A} := S_M(m, f, a, H(p, r))
+  \end{equation*}
+  where $a$ is data relevant to the contract
   indicating which services or goods the merchant will deliver to the customer, and $p$ is the
   merchant's payment information (e.g. his IBAN number) and $r$ is an random nonce.
   The merchant persists $\langle \mathcal{A} \rangle$ and sends it to the customer.