diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/paper/taler.tex | 20 |
1 files changed, 9 insertions, 11 deletions
diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex index 90a5a7009..0da9c14b4 100644 --- a/doc/paper/taler.tex +++ b/doc/paper/taler.tex @@ -56,6 +56,7 @@ % - dirty coin = coin with exposed public key % - fresh coin = coin that was refreshed or is new % - denomination key = exchange's online key used to (blindly) sign coin +% - reserve key = key used to authorize withdrawals from a reserve % - message signing key = exchange's online key to sign exchange messages % - exchange master key = exchange's key used to sign other exchange keys % - owner = entity that knows coin private key @@ -441,8 +442,8 @@ a factor of $\kappa$ for tax evasion are thus unacceptable. Taler ensures that the state can tax {\em transactions}. We must, however, clarify what constitutes a transaction that can be taxed. -As we believe citizens should be in control of their computing, as -well as for practical reasons, we assume that coins can freely be +% As we believe citizens should be in control of their computing, as well as for practical reasons, +We assume that coins can freely be copied between machines, and that coin deletion cannot be verified. Avoiding these assumptions would require extreme measures, like custom hardware supplied by the exchange. Also, it would be inappropriate to @@ -504,9 +505,9 @@ Ideally, the customer's anonymity is limited only by this channel; however, the payment system does additionally reveal that the customer is one of the patrons of the exchange who withdrew enough coin of given denominations. -% FIXME: What does customer-merchant business operation mean? -There are naturally risks that the customer-merchant business operation -may leak identifying information about the customer. +There are naturally risks that the business operation that the +merchant runs on behalf of the customer +may require the merchant to learn identifying information about the customer. We consider information leakage specific to the business logic to be outside of the scope of the design of Taler. @@ -585,7 +586,7 @@ Before a customer can withdraw a coin from the exchange, he has to pay the exchange the value of the coin, as well as processing fees. This is done using other means of payment, such as wire transfers or by having a financial {\em reserve} at the exchange. Taler assumes that -the customer has a {\em withdrawal authorization key} to identify +the customer has a {\em reserve key} to identify himself as authorized to withdraw funds from the reserve. By signing the withdrawal request using this withdrawal authorization key, the customer can prove to the exchange that he is authorized to withdraw @@ -710,18 +711,15 @@ value $K_v$ corresponds to an amount the customer wishes to withdraw. We let $K_s$ denote the exchange's private key corresponding to $K_p$. Now the customer carries out the following interaction with the exchange: -% FIXME: We say withdrawal key in this document, but say reserve key in -% others, so probably withdrawal key should be renamed to reserve key. - % FIXME: These steps occur at very different points in time, so probably % they should be restructured into more of a protocol discription. -% It does create some confusion, like is a withdrawal key semi-ephemeral +% It does create some confusion, like is a reserve key semi-ephemeral % like a linking key? \begin{description} \item[Setup] The customer randomly generates: \begin{itemize} - \item withdrawal key $W := (w_s,W_p)$ with private key $w_s$ and public key $W_p$, + \item reserve key $W := (w_s,W_p)$ with private key $w_s$ and public key $W_p$, \item coin key $C := (c_s,C_p)$ with private key $c_s$ and public key $C_p := c_s G$, \item blinding factor $b$, and commits $\langle W, C, b \rangle$ to disk. \end{itemize} |