gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-SVN] [taler-exchange] branch master updated: minor edits to the


From: gnunet
Subject: [GNUnet-SVN] [taler-exchange] branch master updated: minor edits to the paper, moving refresh around, etc.
Date: Tue, 16 May 2017 11:01:01 +0200

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository exchange.

The following commit(s) were added to refs/heads/master by this push:
     new cddce0f  minor edits to the paper, moving refresh around, etc.
cddce0f is described below

commit cddce0fd6fd3b9870ea230c1cb659a866cac1205
Author: Christian Grothoff <address@hidden>
AuthorDate: Tue May 16 11:01:00 2017 +0200

    minor edits to the paper, moving refresh around, etc.
---
 doc/paper/taler.tex | 102 +++++++++++++++++++++++++++-------------------------
 1 file changed, 53 insertions(+), 49 deletions(-)

diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index 71657fc..9fc5df4 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -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}
 
 

-- 
To stop receiving notification emails like this one, please contact
address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]