aboutsummaryrefslogtreecommitdiff
path: root/doc/paper
diff options
context:
space:
mode:
Diffstat (limited to 'doc/paper')
-rw-r--r--doc/paper/taler.tex88
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.