so many typos ...

1 files changed, 11 insertions, 11 deletions

diff --git a/introduction.tex b/introduction.tex
index 6b857fa..75b6623 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -15,7 +15,7 @@ customers), while a value-based system associates value with typically
 anonymous, digital or physical tokens (such as cash or prepaid credit
 cards).  In practice, these two types of systems are combined, as
 different layers have different (and often conflicting) requirements:
-the payment system used to pay for a cappucchino in a coffee shop is
+the payment system used to pay for a cappuccino in a coffee shop is
 most likely not suitable to buy real estate.  Value-based payment
 systems typically provide more anonymity and convenience but also more
 risk to consumers (as they are responsible to secure the values they
@@ -64,7 +64,7 @@ hand, systems with too much surveillance eliminate personal freedom.
 As the Internet has no standardized payment system, especially not one
 that is capable of instantly, efficiently and securely settling small
 transactions (so-called micropayments), the majority of content on the Web is
-financed by advertisments.  As a result, advertising (and by
+financed by advertisements.  As a result, advertising (and by
 implication, collecting data on users) has been a dominant business
 model on the Internet.  This has not only resulted in a loss of
 independence of publishers---who need to cater to the needs
@@ -110,7 +110,7 @@ supports the more highly ranked goal is preferred:
     wallet software.
 
     This rules out the mandatory usage of specialized
-    hardware such as smartcards or other hardware security modules, as the
+    hardware such as smart cards or other hardware security modules, as the
     software they run cannot be modified by the user.  These components can,
     however, be voluntarily used by merchants, customers or payment processors
     to increase their operational security.
@@ -164,8 +164,8 @@ supports the more highly ranked goal is preferred:
 
   \item \textbf{GNU Taler must be usable.}
 
-    Specifically it must be useable for non-expert customers.  Usability also
-    applies to the integration with mechants, and informs choices about the
+    Specifically it must be usable for non-expert customers.  Usability also
+    applies to the integration with merchants, and informs choices about the
     architecture, such as encapsulating procedures that require cryptographic
     operations into an isolated component with a simple API.
   \item \textbf{GNU Taler must be efficient.}
@@ -231,7 +231,7 @@ already be in another country, and a large number of merchants might already
 have been defrauded with the same coins.
 
 Should the issuer of e-cash be compromised, an attacker could issue coins that
-fail to identify a culprit (or even blame someboy else) when they are
+fail to identify a culprit (or even blame somebody else) when they are
 double-spent.  In an offline e-cash system, the detection of such an event is
 greatly delayed compared to systems with online spending, which can immediately
 detect when more coins are spent than were issued.
@@ -288,7 +288,7 @@ deanonymization of transactions for scenarios involving crime
 \cite{sander1999escrow}, specifically blackmailing and tax evasion.
 
 Unfortunately this does not really work as a countermeasure against
-blackmailing in practice.  As noted in the paper that initialy described such a
+blackmailing in practice.  As noted in the paper that initially described such a
 mechanism for blind signatures \cite{stadler1995fair}, a blackmailer could
 simply request to be paid directly with plain blindly signed coins.
 
@@ -386,7 +386,7 @@ single machine can support around 1000 payments per second, and our
 implementation is easily amenable to further scaling.
 
 The extra computation required in the customer's wallet is in the order of a
-few hundered milliseconds even on typical mobile or tablet devices, and thus
+few hundred milliseconds even on typical mobile or tablet devices, and thus
 barely noticeable.
 
 \begin{figure}
@@ -510,7 +510,7 @@ that it signed.
 
 In this document, we use \emph{coin} to refer to a token of value in an e-cash
 system.  Note that the analogy of a coin does not always hold up, as certain
-types of operations possible in some e-cash schemes, such aspartial spending,
+types of operations possible in some e-cash schemes, such as partial spending,
 divisibility, etc., do not transfer to physical coins.
 
 
@@ -521,7 +521,7 @@ We have the following security and correctness properties for GNU Taler
 \begin{itemize}
   \item \emph{Anonymity} guarantees that transactions cannot be correlated with withdrawals.
   \item \emph{Unforgeability} guarantees that users cannot spend more e-cash than they withdrew.
-  \item \emph{Conservation} guaratees that customers do not lose money due to
+  \item \emph{Conservation} guarantees that customers do not lose money due to
     interrupted protocols or malicious merchants; they can always obtain
     anonymous change or a proof of successful spending.
   \item \emph{Income transparency} guarantees that mutually distrusting parties
@@ -564,7 +564,7 @@ decentralization.
 
 \subsection{Consensus in Decentralized Blockchains}
 
-In decentralized Blockhains, multiple parties must agree on the current state of
+In decentralized Blockchains, multiple parties must agree on the current state of
 the ledger by agreeing on a ``head'' of the chain of blocks.  How to advance
 this head to include new transactions is thus a critical design choice.