diff options
Diffstat (limited to 'doc/paper/taler.tex')
| -rw-r--r-- | doc/paper/taler.tex | 20 |
1 files changed, 10 insertions, 10 deletions
diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex index 7a71d7636..7c913cc1f 100644 --- a/doc/paper/taler.tex +++ b/doc/paper/taler.tex @@ -372,7 +372,7 @@ payment system this means that either entity could spent the associated funds. Assuming the payment system has effective double-spending detection, this means that either entity has to constantly fear that the funds might no longer be available to it. -Thus, ``transfering'' funds by sharing a private key implies that +Thus, ``transferring'' funds by sharing a private key implies that receiving party must trust the sender. In Taler, making funds available by sharing a private key and thus sharing control is {\bf not} considered a {\em transaction} and thus {\bf not} recorded for @@ -467,7 +467,7 @@ private {\em master signing key} of the mint and possibly the auditor. Before a customer can withdraw a coin from the mint, he has to pay the mint the value of the coin, as well as processing fees. This is done using other means of payments, such as SEPA transfers~\cite{sepa}. -The subject line of the transfer must contains {\em withdrawal +The subject line of the transfer must contain {\em withdrawal authorization key}, a public key for digital signatures generated by the customer. When the mint receives a transfer with a public key in the subject, it adds the funds to a {\em reserve} identified by the @@ -488,7 +488,7 @@ with others, they also become owners of the coin. \subsection{Coin spending} -To spent a coin, the coin's owner needs to sign a {\em deposit +To spend a coin, the coin's owner needs to sign a {\em deposit request} specifying the amount, the merchant's account information and a {\em business transaction-specific hash} using the coin's private key. A merchant can then transfer this permission of the @@ -677,17 +677,17 @@ following interaction with the mint: and commits $\langle W, C, b \rangle$ to disk. \item The customer transfers an amount of money corresponding to (at least) $K_p$ to the mint, with $W_p$ in the subject line of the transaction. \item The mint receives the transaction and credits the $W_p$ reserve with the respective amount in its database. - \item The customer sends $S_W(E_b(C_p))$ to the mint to request withdrawl of $C$; here, $E_b$ denotes Chaum-style blinding with blinding factor $b$. - \item The mint checks if the same withdrawl request was issued before; in this case, it sends $S_{K}(E_b(C_p))$ to the customer.\footnote{Here $S_K$ + \item The customer sends $S_W(E_b(C_p))$ to the mint to request withdrawal of $C$; here, $E_b$ denotes Chaum-style blinding with blinding factor $b$. + \item The mint checks if the same withdrawal request was issued before; in this case, it sends $S_{K}(E_b(C_p))$ to the customer.\footnote{Here $S_K$ denotes a Chaum-style blind signature with private key $K_s$.} - If this is a fresh withdrawl request, the mint performs the following transaction: + If this is a fresh withdrawal request, the mint performs the following transaction: \begin{enumerate} \item checks if the reserve $W_p$ has sufficient funds for a coin of value corresponding to $K_p$ - \item stores the withdrawl request $\langle S_W(E_b(C_p)), S_K(E_b(C_p)) \rangle$ in its database for future reference, + \item stores the withdrawal request $\langle S_W(E_b(C_p)), S_K(E_b(C_p)) \rangle$ in its database for future reference, \item deducts the amount corresponding to $K_p$ from the reserve, \item and sends $S_{K}(E_b(C_p))$ to the customer. \end{enumerate} - If the guards for the transaction fail, the mint sends an descriptive error back to the customer, + If the guards for the transaction fail, the mint sends a descriptive error back to the customer, with proof that it operated correctly (i.e. by showing the transaction history for the reserve). \item The customer computes (and verifies) the unblind signature $S_K(C_p) = D_b(S_K(E_b(C_p)))$. The customer writes $\langle S_K(C_p), C_s \rangle$ to disk (effectively adding the coin to the @@ -876,7 +876,7 @@ a fresh coin $\widetilde{C}$ with the same denomination. In the protocol, $\kapp marks $C'_p$ as spent by committing $\langle C', \gamma, S_{C'}(\vec{E}, \vec{B}, \vec{T}) \rangle$ to disk \item The mint sends $S_K(C'_p, \gamma)$ to the customer.\footnote{Instead of $K$, it is also - possible to use any equivalent mint signing key known to the customer here, as $K$ merely + possible to use any equivalent mint signing key known to the customer here, as $K$ merely serves as proof to the customer that the mint selected this particular $\gamma$.} \item The customer commits $\langle C', S_K(C'_p, \gamma) \rangle$ to disk. \item The customer computes $\mathfrak{R} := \left(t_s^{(i)}, C_p^{(i)}, b_i\right)_{i \ne \gamma}$ @@ -964,7 +964,7 @@ transfer. %The legal status of the system needs to be investigated in the various %legal systems of the world. However, given that the system enables -%taxation and is able to impose withdrawl limits and thus is not +%taxation and is able to impose withdrawal limits and thus is not %suitable for money laundering, we are optimistic that states will find %the design desirable. |