From 2a3361961c138b9e66d807466bf696e887b9997e Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Tue, 16 May 2017 15:01:13 +0200 Subject: add section on /payback --- doc/paper/taler.tex | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex index 0bca805ca..6f1be8081 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 @@ -1564,6 +1566,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} % @@ -1782,7 +1802,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. -- cgit v1.2.3 From ef71452e8c0af5d73b786b69646f5dc5851f077f Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Tue, 16 May 2017 15:07:37 +0200 Subject: add sentence on double-spending detection during refresh --- doc/paper/taler.tex | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex index 6f1be8081..774300efa 100644 --- a/doc/paper/taler.tex +++ b/doc/paper/taler.tex @@ -1013,7 +1013,10 @@ 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 + 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 $\langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$. Auditing processes should assure that $\gamma$ is unpredictable until -- cgit v1.2.3 From 4c6d7d9b96a0d12b42ccf0769a9c8f3ebf5f8a4c Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Tue, 16 May 2017 14:45:03 +0200 Subject: proof for lemma 1 and corrolary --- doc/paper/taler.tex | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) (limited to 'doc') diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex index 774300efa..eb06da588 100644 --- a/doc/paper/taler.tex +++ b/doc/paper/taler.tex @@ -1017,8 +1017,8 @@ than the comparable use of zk-SNARKs in ZeroCash~\cite{zerocash}. 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 - $\langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$. + 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. \\ % @@ -1366,21 +1366,29 @@ The exchange can detect and prove double-spending. \end{lemma} \begin{proof} +A coin can only be spent by either 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 as 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} +% only holds given sufficient time Customers can either obtain proof-of-payment or their money back. \end{lemma} \begin{proof} + + \end{proof} \begin{lemma} -- cgit v1.2.3 From 5bece999b8e0c2ad9ff17997dc371872890e4f12 Mon Sep 17 00:00:00 2001 From: Florian Dold Date: Tue, 16 May 2017 15:09:02 +0200 Subject: first stab at proofs --- doc/paper/taler.tex | 38 +++++++++++++++++++++++++------------- 1 file changed, 25 insertions(+), 13 deletions(-) (limited to 'doc') diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex index eb06da588..ea096ba6f 100644 --- a/doc/paper/taler.tex +++ b/doc/paper/taler.tex @@ -1361,16 +1361,16 @@ 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 either running the deposit protocol or the refresh +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 as a set of refresh-records and +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} @@ -1383,33 +1383,45 @@ that the total value exceeds the coin's value. \begin{lemma} % only holds given sufficient time -Customers can either obtain proof-of-payment or their money back. +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} -- cgit v1.2.3