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

minor edits to the paper, moving refresh around, etc.

Browse Source
This commit is contained in:
Christian Grothoff 2017-05-16 11:01:00 +02:00
parent 709e53be6e
commit cddce0fd6f
No known key found for this signature in database
GPG Key ID: 939E6BE1E29FC3CC
1 changed files with 53 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

102
doc/paper/taler.tex
View File

@ -665,6 +665,8 @@ spending operation as the owner of a coin should not have to pay
not used for money laundering or tax evasion, the refreshing protocol
assures that the owner stays the same.
% FIXME: This paragraph could likely be removed and be replaced
% by the proof if we have space.
The refresh protocol has two key properties: First, the exchange is
unable to link the fresh coin's public key to the public key of the
dirty coin. Second, it is assured that the owner of the dirty coin
@ -696,8 +698,7 @@ customers and merchants and is certified by the auditors.
We avoid asking either customers or merchants to make trust decisions
about individual exchanges. Instead, they need only select the auditors.
Auditors must sign all the exchange's keys including, the individual
denomination keys.
Auditors must sign all the exchange's public keys.
As we are dealing with financial transactions, we explicitly describe
whenever entities need to safely write data to persistent storage.
@ -886,7 +887,8 @@ We now describe the refresh protocol whereby a dirty coin $C'$ of
denomination $K$ is melted to obtain a fresh coin $\widetilde{C}$. To
simplify the description, this section describes the case where one
{\em unspent} dirty coin (for example, from an aborted transaction) is
exchanged for a fresh coin of the same denomination. In practice,
exchanged for a fresh coin of the same denomination. We have again
simplified the exposition by creating only one fresh coin. In practice,
Taler uses a natural extension where multiple fresh coins of possibly
many different denominations are generated at the same time. For this,
the wallet simply specifies an array of coins wherever the protocol
@ -1029,6 +1031,25 @@ devolve into a payment system where both sides can be anonymous, and
thus no longer provide taxability.
\subsection{Refunds}
The refresh protocol offers an easy way to enable refunds to
customers, even if they are anonymous. Refunds are supported
by including a public signing key of the merchant in the transaction
details, and having the customer keep the private key of the spent
coins on file.
Given this, the merchant can simply sign a {\em refund confirmation}
and share it with the exchange and the customer. Assuming the
exchange has a way to recover the funds from the merchant, or has not
yet performed the wire transfer, the exchange can simply add the value
of the refunded transaction back to the original coin, re-enabling
those funds to be spent again by the original customer. This customer
can then use the refresh protocol to anonymously melt the refunded
coin and create a fresh coin that is unlinkable to the refunded
transaction.
\subsection{Error handling}
During operation, there are three main types of errors that are
@ -1054,21 +1075,20 @@ response to the client or take appropriate legal action against the
faulty exchange.
The third case are transient failures, such as network failures or
temporary hardware failures at the exchange service provider. Here, the
client may receive an explicit protocol indication, such as an HTTP
response code ``500 INTERNAL SERVER ERROR'' or simply no response.
The appropriate behavior for the client is to automatically retry
after 1s, and twice more at randomized times within 1 minute.
If those three attempts fail, the user should be informed about the
delay. The client should then retry another three times within the
next 24h, and after that time the auditor should be informed about the outage.
Using this process, short term failures should be effectively obscured
from the user, while malicious behavior is reported to the auditor who
can then presumably rectify the situation, using methods such as
shutting down the operator and helping customers to regain refunds for
coins in their wallets. To ensure that such refunds are possible, the
operator is expected to always provide adequate securities for the
amount of coins in circulation as part of the certification process.
temporary hardware failures at the exchange service provider. Here,
the client may receive an explicit protocol indication, or simply no
response. The appropriate behavior for the client is to automatically
retry a few times with back-off. If this still fails, the user can,
depending on the type of operation, either attempt to recover the now
dirty coin using the refresh protocol, or notify the auditor about the
outage. Using this process, short term failures should be effectively
obscured from the user, while malicious behavior is reported to the
auditor who can then presumably rectify the situation, using methods
such as shutting down the operator and helping customers to regain
refunds for coins in their wallets. To ensure that such refunds are
possible, the operator is expected to always provide adequate
securities for the amount of coins in circulation as part of the
certification process.
%As with support for fractional payments, Taler addresses these
@ -1077,24 +1097,6 @@ amount of coins in circulation as part of the certification process.
%the new coin.
\subsection{Refunds}
The refresh protocol offers an easy way to enable refunds to
customers, even if they are anonymous. Refunds are supported
by including a public signing key of the merchant in the transaction
details, and having the customer keep the private key of the spent
coins on file.
Given this, the merchant can simply sign a {\em refund confirmation}
and share it with the exchange and the customer. Assuming the
exchange has a way to recover the funds from the merchant, or has not
yet performed the wire transfer, the exchange can simply add the value
of the refunded transaction back to the original coin, re-enabling
those funds to be spent again by the original customer. This customer
can then use the refresh protocol to anonymously melt the refunded
coin and create a fresh coin that is unlinkable to the refunded
transaction.
\section{Experimental results}
%\begin{figure}[b!]
@ -1373,13 +1375,13 @@ data being persisted are represented in between $\langle\rangle$.
\item[$\overline{C^{(i)}_p}$]{Public coin keys computed from $\overline{c_s^{(i)}}$ by the verifier}
\end{description}
\newpage
\section{Taxability arguments}
We assume the exchange operates honestly when discussing taxability.
We feel this assumption is warranted mostly because a Taler exchange
requires licenses to operate as a financial institution, which it
risks loosing if it knowingly facilitates tax evasion.
risks loosing if it knowingly facilitates tax evasion.
We also expect an auditor monitors the exchange similarly to how
government regulators monitor financial institutions.
In fact, our auditor software component gives the auditor read access
@ -1397,13 +1399,14 @@ An honest exchange keeps any funds being refreshed if the reveal
phase is never carried out, does not match the commitment, or shows
an incorrect commitment. As a result, a customer dishonestly
refreshing a coin looses their money if they have more than one
dishonest commitment. They have a $1 \over \kappa$ chance of their
dishonest commitment. If they make exactly one dishonest
commitment, they have a $1 \over \kappa$ chance of their
dishonest commitment being selected for the refresh.
\end{proof}
We say a coin is {\em controlled} by a user if the user's wallet knows
We say a coin $C$ is {\em controlled} by a user if the user's wallet knows
its secret scalar $c_s$, the signature $S$ of the appropriate denomination
key on its public key $C_s$, and the residual value of the coin.
key on its public key $C_s$, and the residual value of the coin.
We assume the wallet cannot loose knowledge of a particular coin's
key material, and the wallet can query the exchange to learn the
@ -1412,13 +1415,13 @@ a coin. A wallet may loose the monetary value associated with a coin
if another wallet spends it however.
We say a user Alice {\em owns} a coin $C$ if only Alice's wallets can
gain control of $C$ using standard interactions with the exchange.
gain control of $C$ using standard interactions with the exchange.
In other words, ownership means exclusive control not just in the
present, but in the future even if another user interacts with the
exchange.
\begin{theorem}
Let $C$ denote a coin controlled by users Alice and Bob.
Let $C$ denote a coin controlled by users Alice and Bob.
Suppose Bob creates a coin $C'$ from $C$ using the refresh protocol.
Assuming the exchange and Bob operated the refresh protocol correctly,
and that they continue to operate the linking protocol
@ -1429,7 +1432,7 @@ then Alice can gain control of $C'$ using the linking protocol.
\begin{proof}
Alice may run the linking protocol to obtain all transfer keys $T^i$,
bindings $B^i$ associated to $C$, and those coins denominations,
including the $T'$ for $C'$.
including the $T'$ for $C'$.
We assumed both the exchange and Bob operated the refresh protocol
correctly, so now $c_s T'$ is the seed from which $C'$ was generated.
@ -1469,7 +1472,7 @@ Also let $d$ and $e$ denote the private and public exponents, respectively.
In effect, coin withdrawal transcripts consist of numbers
$b m^d \mod n$ where $m$ is the FDH of the coin's public key
and $b$ is the blinding factor, while coin deposits transcripts
consist of only $m^d \mon n$.
consist of only $m^d \mod n$.
Of course, if the adversary can link coins then they can compute
the blinding factors as $b m^d / m^d \mod n$. Conversely, if the
@ -1481,7 +1484,7 @@ We now know the following because Taler used SHA512 adopted to be
a FDH to be the blinding factor.
\begin{corollary}
Assuming no refresh operation,
Assuming no refresh operation,
any PPT adversary with an advantage for linking Taler coins gives
rise to an adversary with an advantage for recognizing SHA512 output.
\end{corollary}
@ -1503,7 +1506,7 @@ rise to an adversary with an advantage for recognizing SHA512 output.
We may now remove the encrpytion by appealing to the random oracle model
\cite{BR-RandomOracles}.
\begin{lemma}[\cite[??]{??}]
\begin{lemma}[\cite{??}]
Consider a protocol that commits to random data by encrypting it
using a secret derived from a Diffe-Hellman key exchange.
In the random oracle model, we may replace this encryption with
@ -1514,11 +1517,11 @@ to the same secret.
\begin{proof}
We work with the usual instantiation of the random oracle model as
returning a random string and placing it into a database for future
queries.
queries.
We take the random number generator that drives this random oracle
to be the random number generator used to produce the random data
that we encrypt in the old encryption based version of Taler.
that we encrypt in the old encryption based version of Taler.
Now our random oracle scheme gives the same result as our scheme
that encrypts random data, so the encryption becomes superfluous
and may be omitted.
@ -1538,6 +1541,7 @@ proves that out linking protocol \S\ref{subsec:linking} does not
degrade privacy.
\end{document}