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

fixing #3779: typos in paper

Browse Source
This commit is contained in:
Christian Grothoff 2015-04-22 18:41:50 +02:00
parent 4ece9c192c
commit 6878f2e793
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
doc/paper/taler.tex
View File

@ -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.