taler/exchange
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Jeffrey Burdges 2017-05-16 15:15:28 +02:00
commit 09cd669283
No known key found for this signature in database
GPG Key ID: ABAC7FD1CC100A74
1 changed files with 68 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

90
doc/paper/taler.tex
View File

@ -871,7 +871,9 @@ with signature $\widetilde{C} := S_K(\FDH_K(C_p))$
public key. public key.
\item \item
The merchant creates a signed contract 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, where $m$ is an identifier for this transaction, $f$ is the price of the offer,
and $a$ is data relevant and $a$ is data relevant
to the contract indicating which services or goods the merchant will 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 for $i \in \{1,\ldots,\kappa\}$ and sends a signed commitment
$S_{C'}(\vec{B}, \vec{T_p})$ to the exchange. $S_{C'}(\vec{B}, \vec{T_p})$ to the exchange.
\item % [200 OK / 409 CONFLICT] \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
marks $C'_p$ as spent by persisting to cover the value of the fresh coins to be generated and prevent
$\langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$. 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 Auditing processes should assure that $\gamma$ is unpredictable until
this time to prevent the exchange from assisting tax evasion. \\ this time to prevent the exchange from assisting tax evasion. \\
% %
@ -1372,47 +1377,67 @@ protocol is never used.
\subsection{Exculpability arguments} \subsection{Exculpability arguments}
\begin{lemma} \begin{lemma}\label{lemma:double-spending}
The exchange can detect and prove double-spending. The exchange can detect and prove double-spending.
\end{lemma} \end{lemma}
\begin{proof} \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} \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} \begin{lemma}
Merchants and customers can verify double-spending proofs. % only holds given sufficient time
Customers can either obtain proof-of-payment or their money back, even
when the merchant is faulty.
\end{lemma} \end{lemma}
\begin{proof} \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} \end{proof}
\begin{corollary}
\begin{lemma} If a customer paid for a contract, they can prove it by showing
Customers can either obtain proof-of-payment or their money back. the deposit permissions for all coins.
\end{lemma} \end{corollary}
\begin{proof}
\end{proof}
\begin{lemma}
If a customer paid for a contract, they can prove it.
\end{lemma}
\begin{proof}
\end{proof}
\begin{lemma} \begin{lemma}
The merchant can issue refunds, and only to the original customer. The merchant can issue refunds, and only to the original customer.
\end{lemma} \end{lemma}
\begin{proof} \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} \end{proof}
\begin{theorem} \begin{theorem}
The protocol prevents double-spending and provides exculpability. The protocol prevents double-spending and provides exculpability.
\end{theorem} \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 particular, in providing the cryptographic proofs as evidence none of
the participants have to disclose their core secrets. 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} %\subsection{System Performance}
% %
@ -1798,7 +1841,10 @@ coin first.
the exchange persists $\langle \mathcal{L} \rangle$ the exchange persists $\langle \mathcal{L} \rangle$
and notifies the merchant that locking was successful. and notifies the merchant that locking was successful.
\item\label{contract2} The merchant creates a digitally signed contract \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 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. 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. The merchant persists $\langle \mathcal{A} \rangle$ and sends it to the customer.