diff options
Diffstat (limited to 'doc/paper')
| -rw-r--r-- | doc/paper/taler.tex | 88 |
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. |