summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2015-04-22 18:41:50 +0200
committerChristian Grothoff <christian@grothoff.org>2015-04-22 18:41:50 +0200
commit6878f2e79365c78436a9977e2533d730bdaecaa6 (patch)
tree7116768e2bfd9512a724baed94936a2859562fa8 /doc
parent4ece9c192cebed7a3cf195f377a8e86da1f726e3 (diff)
downloadexchange-6878f2e79365c78436a9977e2533d730bdaecaa6.tar.gz
exchange-6878f2e79365c78436a9977e2533d730bdaecaa6.tar.bz2
exchange-6878f2e79365c78436a9977e2533d730bdaecaa6.zip
fixing #3779: typos in paper
Diffstat (limited to 'doc')
-rw-r--r--doc/paper/taler.tex20
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.