summaryrefslogtreecommitdiff
path: root/doc/system
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2020-07-22 23:56:52 +0200
committerChristian Grothoff <christian@grothoff.org>2020-07-22 23:56:52 +0200
commit0e808b648a56e3e4e17d6e03ce776b0b7a422f25 (patch)
tree59720c0b409f30fc6520526ba7170b0ba60c255c /doc/system
parentc8a370d9111cee69b6d9b6edc177dcc58eec976a (diff)
downloadexchange-0e808b648a56e3e4e17d6e03ce776b0b7a422f25.tar.gz
exchange-0e808b648a56e3e4e17d6e03ce776b0b7a422f25.tar.bz2
exchange-0e808b648a56e3e4e17d6e03ce776b0b7a422f25.zip
fix misc typos
Diffstat (limited to 'doc/system')
-rw-r--r--doc/system/conclusions.tex2
-rw-r--r--doc/system/introduction.tex2
-rw-r--r--doc/system/taler/design.tex10
-rw-r--r--doc/system/taler/implementation.tex4
-rw-r--r--doc/system/taler/security.tex4
5 files changed, 11 insertions, 11 deletions
diff --git a/doc/system/conclusions.tex b/doc/system/conclusions.tex
index 1f72285f..84c78452 100644
--- a/doc/system/conclusions.tex
+++ b/doc/system/conclusions.tex
@@ -74,7 +74,7 @@ online, as the discretion of parents.
%
%\subsection*{NFC Wallet}
%
-%\subsection*{large, scaleable deployment}
+%\subsection*{large, scalable deployment}
%I.e. sharding, db replication, load balancer(s)
%
%\subsection*{Hardware security module for exchange}
diff --git a/doc/system/introduction.tex b/doc/system/introduction.tex
index ba1da708..9604f056 100644
--- a/doc/system/introduction.tex
+++ b/doc/system/introduction.tex
@@ -108,7 +108,7 @@ supports the more highly ranked goal is preferred:
%Especially if a payment system is to be used for microtransactions for online
%content, the privacy of buyers becomes important: if micropayments were more
-%commonplace, the transaction data could be used to collect extremely detailled
+%commonplace, the transaction data could be used to collect extremely detailed
%profiles of users. Unfortunately practically no commercially used payment
%system has strong anonymity guarantees.
diff --git a/doc/system/taler/design.tex b/doc/system/taler/design.tex
index de91daa1..c9e45f9b 100644
--- a/doc/system/taler/design.tex
+++ b/doc/system/taler/design.tex
@@ -309,7 +309,7 @@ For purposes of anti-money-laundering and taxation, a more detailed audit of
the merchant's transactions can be desirable. A government tax authority can
request the merchant to reveal the business agreement details that match the
contract terms hash recorded with the exchange. If a merchant is not able to
-provide theses values, they can be subjected to financial penalties by the
+provide these values, they can be subjected to financial penalties by the
state in relation to the amount transferred by the traditional currency
transfer.
@@ -398,7 +398,7 @@ Yet another type of fee are the \emph{wire transfer fees}, which are charged
by the exchange for every wire transfer to a merchant in order to compensate for
the cost of making a transaction in the underlying bank system. The wire
transfer fees encourage merchants to choose longer aggregation periods, as the
-fee is charged per transaction and independant of the amount.
+fee is charged per transaction and independent of the amount.
Merchants can also specify the maximum wire fee they are willing to cover for
customers, along with an \emph{amortization rate} for the wire fees. In case
@@ -752,7 +752,7 @@ fails to do so, coins may {\em expire}, resulting in a loss for the coin's
owner. Dirty coins can also expire. In practice, this happens if the melt fee
exceeds the residual value of the dirty coin. To {\em melt} a coin, the
wallet must commit to one or more {\em planchets} and then demonstrate honesty
-when the committment made for the {\em refresh session} is checked during the
+when the commitment made for the {\em refresh session} is checked during the
{\em reveal} step. If the wallet was honest, {\em reveal} yields {\em fresh
coins}.
@@ -1029,7 +1029,7 @@ GNU Taler
by giving change online (Onl.) or by divisible coins that support offline
operation (Off.)?
\item \textbf{Receipts \& Refunds.}
- The customer either can prove that they payed for
+ The customer either can prove that they paid for
a contract, or they can get their (unlinkable) money back.
Also merchants can issue refunds for completed transactions.
These operations must not introduce linkability or otherwise
@@ -1121,7 +1121,7 @@ Some of the most important decisions for the design of blockchains are the follo
consensus protocols. Their proposed system does not have any incentives
for validators.
- Avalance \cite{rocket2018snowflake} has been proposed as a scalable
+ Avalanche \cite{rocket2018snowflake} has been proposed as a scalable
Byzantine Consensus algorithm for use with blockchains. It is based on a
gossip protocol and is only shown to work in the synchronous model.
diff --git a/doc/system/taler/implementation.tex b/doc/system/taler/implementation.tex
index 4b095b77..b49763c6 100644
--- a/doc/system/taler/implementation.tex
+++ b/doc/system/taler/implementation.tex
@@ -577,7 +577,7 @@ We now define a fallback, which is transparently implemented in the reference me
In addition to indicating that a payment is required for a resource in the HTTP status code and header,
the merchant includes a fallback URL in the body of the ``402 Payment Required'' response. This URL must have the custom URL scheme
\texttt{taler}, and contains the contract terms URL (and other Taler-specific settings normally specified in headers)
-as parameters. The above payment would include a link (labled, e.g., ``Pay with GNU Taler'') to the following URL, encoding
+as parameters. The above payment would include a link (labeled, e.g., ``Pay with GNU Taler'') to the following URL, encoding
the same information as the headers:
\begin{lstlisting}[style=myhttp]
taler:pay?*\break\contl*contract_url=*\break\contl*https%3A%2F%2Falice-shop.example.com%2Fcontract%3Fproduct%3Dessay-24.pdf*\break\contl*&resource_url=*\break\contl*https%3A%2F%2Falice-shop.example.com%2Fessay-24.pdf
@@ -908,7 +908,7 @@ The following APIs are offered by the exchange:
the merchant additionally can use the exchange's \texttt{/transfers/\$WTID} API that returns the list of deposits for a wire transfer
identifier (WTID) included in the wire transfer to the merchant, as well as the \texttt{/deposits/\$H\_WIRE/\$MERCHANT\_PUB/\$H\_CONTRACT\_TERMS/\$COIN\_PUB} API to look up
which wire transfer included the payment for a given deposit.
- \item[Refresh] Refreshing consists of two stages. First, using \texttt{/coins/\$COIN\_PUB/melt} an old, possibly dirty coin is melted and thus devaluted. The committment made by the wallet during the melt and the resulting $\gamma$-challenge from the exchange are associated with a {\em refresh session}. Then, using \texttt{/refreshes/\$RCH/reveal} the wallet can answer the challenge and obtain fresh coins as change. Finally, \texttt{/coins/\$COIN\_PUB/link} provides the link deterrent against refresh abuse.
+ \item[Refresh] Refreshing consists of two stages. First, using \texttt{/coins/\$COIN\_PUB/melt} an old, possibly dirty coin is melted and thus devaluted. The commitment made by the wallet during the melt and the resulting $\gamma$-challenge from the exchange are associated with a {\em refresh session}. Then, using \texttt{/refreshes/\$RCH/reveal} the wallet can answer the challenge and obtain fresh coins as change. Finally, \texttt{/coins/\$COIN\_PUB/link} provides the link deterrent against refresh abuse.
\item[Refunds] The refund API (\texttt{/coins/\$COIN\_PUB/refund}) can ``undo'' a deposit if the merchant gave their signature, and the aggregation deadline
for the payment has not occurred yet.
\item[Recoup] The recoup API (\texttt{/coins/\$COIN\_PUB/recoup}) allows customers to be compensated
diff --git a/doc/system/taler/security.tex b/doc/system/taler/security.tex
index 99c8e052..cf0128a0 100644
--- a/doc/system/taler/security.tex
+++ b/doc/system/taler/security.tex
@@ -759,7 +759,7 @@ Taler. Similar to \cite{bellare2006code} we assume that the game and adversary
terminate in finite time, and thus random choices made by the challenger and
adversary can be taken from a finite sample space.
-All games except income transpacency return $1$ to indicate that the adversary
+All games except income transparency return $1$ to indicate that the adversary
has won and $0$ to indicate that the adversary has lost. The income
transparency game returns $0$ if the adversary has lost, and a positive
``laundering ratio'' if the adversary won.
@@ -1666,7 +1666,7 @@ In particular, the following features are left out of the formal discussion:
behalf of the merchant to obtain proof of their on-time payment, which can
be used in a later arbitration if necessary. Alternatively, the customer
can ask the exchange to undo the partial payments, though this requires the
- exchange to know (or learn from the customer) the exact amount to be payed
+ exchange to know (or learn from the customer) the exact amount to be paid
for the contract.
%A complication in practice is that merchants may not want to reveal their