gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-exchange] branch master updated: fix misc typos


From: gnunet
Subject: [taler-exchange] branch master updated: fix misc typos
Date: Wed, 22 Jul 2020 23:56:55 +0200

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository exchange.

The following commit(s) were added to refs/heads/master by this push:
     new 0e808b64 fix misc typos
0e808b64 is described below

commit 0e808b648a56e3e4e17d6e03ce776b0b7a422f25
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Wed Jul 22 23:56:52 2020 +0200

    fix misc typos
---
 .../exchange-template/config/exchange-common.conf  |  4 +-
 contrib/gana                                       |  2 +-
 contrib/uncrustify-mode.el                         |  2 +-
 contrib/uncrustify_precommit                       |  2 +-
 doc/paper/figs/refresh.tex                         |  4 +-
 doc/paper/offline.tex                              | 10 ++--
 doc/paper/postquantum.tex                          | 60 +++++++++++-----------
 doc/paper/taler.bib                                |  2 +-
 doc/paper/taler.tex                                |  4 +-
 doc/paper/taler_FC2016.txt                         |  4 +-
 doc/paper/taler_FC2017.txt                         |  4 +-
 doc/system/conclusions.tex                         |  2 +-
 doc/system/introduction.tex                        |  2 +-
 doc/system/taler/design.tex                        | 10 ++--
 doc/system/taler/implementation.tex                |  4 +-
 doc/system/taler/security.tex                      |  4 +-
 src/auditor/report-lib.c                           |  2 +-
 src/auditor/report-lib.h                           |  4 +-
 src/exchange/test_taler_exchange_httpd.conf        |  4 +-
 src/exchangedb/test_exchangedb.c                   |  2 +-
 src/include/taler_auditor_service.h                |  2 +-
 src/include/taler_mhd_lib.h                        |  2 +-
 src/lib/exchange_api_handle.c                      |  2 +-
 src/testing/test_exchange_api_twisted.c            |  3 +-
 src/testing/test_exchange_api_twisted.conf         |  4 +-
 src/testing/testing_api_cmd_serialize_keys.c       |  2 +-
 26 files changed, 73 insertions(+), 74 deletions(-)

diff --git a/contrib/exchange-template/config/exchange-common.conf 
b/contrib/exchange-template/config/exchange-common.conf
index 4f17d3ec..5694995b 100644
--- a/contrib/exchange-template/config/exchange-common.conf
+++ b/contrib/exchange-template/config/exchange-common.conf
@@ -64,7 +64,7 @@ ENABLE_CREDIT = YES
 
 # Wire fees are specified by wire method, NOT by wire plugin.
 [fees-x-taler-bank]
-# Fees for the forseeable future...
+# Fees for the foreseeable future...
 # If you see this after 2018, update to match the next 10 years...
 WIRE-FEE-2018 = EUR:0.01
 WIRE-FEE-2019 = EUR:0.01
@@ -89,7 +89,7 @@ CLOSING-FEE-2026 = EUR:0.01
 CLOSING-FEE-2027 = EUR:0.01
 
 [fees-sepa]
-# Fees for the forseeable future...
+# Fees for the foreseeable future...
 # If you see this after 2018, update to match the next 10 years...
 WIRE-FEE-2018 = EUR:0.01
 WIRE-FEE-2019 = EUR:0.01
diff --git a/contrib/gana b/contrib/gana
index 0a9293b4..a4f1ad6f 160000
--- a/contrib/gana
+++ b/contrib/gana
@@ -1 +1 @@
-Subproject commit 0a9293b4cf1df97c395dc96d7a8ba96cc1fb4664
+Subproject commit a4f1ad6f6c27a874d2170beedf15bcba11323a62
diff --git a/contrib/uncrustify-mode.el b/contrib/uncrustify-mode.el
index 83868c6a..cf615b02 100755
--- a/contrib/uncrustify-mode.el
+++ b/contrib/uncrustify-mode.el
@@ -114,7 +114,7 @@
                               (message "uncrustify error: <%s> <%s>" ret 
(buffer-string)))
                             nil))))))
 
-          ;; This goto-line is outside the save-excursion becuase it'd get
+          ;; This goto-line is outside the save-excursion because it'd get
           ;; removed otherwise.  I hate this bug. It makes things so ugly.
           (goto-line original-line)
           (not result)))
diff --git a/contrib/uncrustify_precommit b/contrib/uncrustify_precommit
index fd29998c..24873330 100755
--- a/contrib/uncrustify_precommit
+++ b/contrib/uncrustify_precommit
@@ -30,6 +30,6 @@ if [ $RET = 1 ];
 then
   echo "Run"
   echo "uncrustify --no-backup -c uncrustify.cfg ${crustified}"
-  echo "before commiting."
+  echo "before committing."
 fi
 exit $RET
diff --git a/doc/paper/figs/refresh.tex b/doc/paper/figs/refresh.tex
index 6908527e..7575e453 100644
--- a/doc/paper/figs/refresh.tex
+++ b/doc/paper/figs/refresh.tex
@@ -134,7 +134,7 @@
       \item[$\beta_\gamma$] $:= \big[ B_\gamma^{(i)} \big]_i$
       \item[$\cal S$] $:= \left[ S_{DK^{(i)}}( B_\gamma^{(i)} ) \right]_i$ \\ 
\smallskip
 
-      \item[$Z$] Cut-and-choose missmatch information
+      \item[$Z$] Cut-and-choose mismatch information
       \end{description}
     \end{minipage}
   \end{figure}
@@ -165,7 +165,7 @@
            minimum height = 10cm
          ] (h2) at (4, 0) {};
          \node[above = 0cm of h1] {Customer};
-         \node[above = 0cm of h2] {Exchagne};
+         \node[above = 0cm of h2] {Exchange};
 
          \path[->, color = MidnightBlue, very thick, >=stealth]
            (-5, 4.5) edge
diff --git a/doc/paper/offline.tex b/doc/paper/offline.tex
index bc4ac0ab..d4ddeb1d 100644
--- a/doc/paper/offline.tex
+++ b/doc/paper/offline.tex
@@ -74,11 +74,11 @@ $n_\mu$ denote the maximum number of coins returned by a 
refresh.
 
 \smallskip
 
-Let $\iota$ denote a coin idetity paramater that
+Let $\iota$ denote a coin idetity parameter that
  links together the different commitments but must reemain secret
  from the exchange. 
 
-Let $n_\nu$ denote the identity security paramater.
+Let $n_\nu$ denote the identity security parameter.
 An online coin's identity commitment $\Nu$ is the empty string.
 In the offline coin case, we begin with a reserve public key $R$
 and a private identity commitment seed $\nu$.  
@@ -97,8 +97,8 @@ A coin $(C,\Nu,S)$ consists of
   an optional set of offline identity commitments $\Nu = \{\Nu_k | k \in 
\Gamma \}$
   an RSA-FDH signature $S = S_d(\FDH(C) * \Pi_{k \in \Gamma} \FDH(\Nu_k))$ by 
a denomination key $d$.
 A coin is spent by signing a contract with $C$.  The contract must
-specify the recipiant merchant and what portion of the value denoted
-by the denomination $d$ they recieve.
+specify the recipient merchant and what portion of the value denoted
+by the denomination $d$ they receive.
 
 There was of course a blinding factor $b$ used in the creation of
 the coin's signature $S$.  In addition, there was a private seed $s$
@@ -114,7 +114,7 @@ We generate $\nu = H("Offline" || s)$ from $s$ as well,
 We begin refresh with a possibly tainted coin $(C,S)$ whose value
 we wish to save by refreshing it into untainted coins.  
 
-In the change sitaution, our coin $(C,\Nu,S)$ was partially spent and 
+In the change situation, our coin $(C,\Nu,S)$ was partially spent and 
 retains only a part of the value determined by the denominaton $d$.
 
 For $x$ amongst the symbols $c$, $C$, $b$, and $s$,
diff --git a/doc/paper/postquantum.tex b/doc/paper/postquantum.tex
index 9a4f2e9a..9fc73205 100644
--- a/doc/paper/postquantum.tex
+++ b/doc/paper/postquantum.tex
@@ -95,7 +95,7 @@ when coins are double spent \cite{B??}.
 Importantly, there are reasons why exchanges must replace coins that
 do not involve actual financial transactons, like to reissue a coin
 before the exchange rotates the denomination key that signed it, or
-protect users' anonymity after a merchant recieves a coin, but fails
+protect users' anonymity after a merchant receives a coin, but fails
 to process it or deliver good.
 
 In Taler, coins can be partially spent by signing with the coin's key
@@ -111,7 +111,7 @@ as well as for coin replacement due to denomination key 
roration.
 
 If this protocol were simply a second transaction, then customers
 would retain information theoreticaly secure anonymity.  
-In Taler however, we require that the exchange learns acurate income
+In Taler however, we require that the exchange learns accurate income
 information for merchants.  If we use a regular transaction, then
 a customer could conspire to help the merchant hide their income
 \cite[]{Taler??}.
@@ -138,14 +138,14 @@ These provide strong post-quantum security so long as the 
underlying
 scheme remains secure; however, these schemes' youth leaves them
 relatively untested.
 
-Second, we propose a hash based scheme whose anonymity garentee needs
+Second, we propose a hash based scheme whose anonymity guarantee needs
 only the one-way assumption on our hash function.  In this scheme,
-the vible security paramater is numerically far smaller than in the
+the vible security parameter is numerically far smaller than in the
 key exchange systems, but covers query complexity which we believe
 suffices.
 
 We describe this hash based proof-of-encryption-to-self scheme to
-align the discription of all our schemes.
+align the description of all our schemes.
 
 ...
 
@@ -191,9 +191,9 @@ We label place holders $\eta$, $\lambda$, $\Lambda$, $\mu$, 
and $\Mu$
 for key material involved in post-quantum operations.  
 We view $\Lambda$ and $\Mu$ as public keys with respective
  private keys $\lambda$ and $\mu$, and
-$\eta$ as the symetric key resulting from the key exchange between them.
+$\eta$ as the symmetric key resulting from the key exchange between them.
 
-We need effeciently computable functions
+We need efficiently computable functions
   $\CPK$, $\CSK$, $\LPK$, $\LSK$, $\KEX_2$ and $\KEX_3$  such that 
 \begin{itemize}
 \item  $\mu = \CSK(s)$ for a random bitstring $s$,
@@ -216,10 +216,10 @@ A coin $(C,\Mu,S)$ consists of
   a post-quantum public key $\Mu$, and
   an RSA-FDH signature $S = S_d(C || \Mu)$ by a denomination key $d$.
 A coin is spent by signing a contract with $C$.  The contract must
-specify the recipiant merchant and what portion of the value denoted
-by the denomination $d$ they recieve.
+specify the recipient merchant and what portion of the value denoted
+by the denomination $d$ they receive.
 If $\Mu$ is large, we may replace it by $H(C || \Mu)$ to make signing
-contracts more efficent.
+contracts more efficient.
 
 There was of course a blinding factor $b$ used in the creation of
 the coin's signature $S$.  In addition, there was a private seed $s$
@@ -234,7 +234,7 @@ $$ c = H(\textrm{"Ed25519"} || s)
 We begin refresh with a possibly tainted coin $(C,\Mu,S)$ that
 we wish to refresh into $n \le \theta$ untainted coins.  
 
-In the change sitaution, our coin $(C,\Mu,S)$ was partially spent and 
+In the change situation, our coin $(C,\Mu,S)$ was partially spent and 
 retains only a part of the value determined by the denominaton $d$.
 There is usually no denomination that matchets this risidual value
 so we must refresh from one coin into $n \le \theta$.
@@ -291,8 +291,8 @@ In other words, $c'$, $\mu'$, and $b_j$ are derived from 
$s_j$,
 \item  For $j = 1 \cdots \kappa$ except $\gamma$:
    \begin{itemize}
    \item  Create a proof $\lambda_j^{\textrm{proof}}$ that
-          $\lambda_j$ is compatable with $\Lambda_j$ and $\Mu$.
-   \item  Set a responce tuple
+          $\lambda_j$ is compatible with $\Lambda_j$ and $\Mu$.
+   \item  Set a response tuple
           $R_j = (\zeta_j,l_j,\lambda_j,\lambda_j^{\textrm{proof}})$.
    \end{itemize}
 \item  Send $S_C(R_j \quad\textrm{for}\quad j \ne \gamma )$.
@@ -321,7 +321,7 @@ We could optionally save long-term storage space by
 replacing $\Gamma_*$ with both $\Gamma_{\gamma,0}$ and
  $S_C(\Eta_{j,i} \quad\textrm{for}\quad j \ne \gamma )$.
 It's clear this requires the wallet send that signature in some phase,
-but also the wallet must accept a phase 2 responce to a phase 1 request.
+but also the wallet must accept a phase 2 response to a phase 1 request.
 
 \smallskip
 
@@ -356,7 +356,7 @@ This rigidity makes constructing signature schemes with 
SIDH hard
 \cite{??SIDHsig??}, but does not impact our use case.  
 
 We let $\mu$ and $\Mu$ be the SIDH 2-torsion private and public keys,
-repectively.  We simlarly let $\lambda$ and $\Lambda$ be the
+respectively.  We similarly let $\lambda$ and $\Lambda$ be the
 SIDH 3-torsion private and public keys.  
 
 We envision the 2-torsion secret key generation function $\CSK(s)$
@@ -396,7 +396,7 @@ groups \cite{??,??}, but also a reasuring relationship with 
NP-hard
 problems.
 
 We again let $\mu$ and $\Mu$ denote the Alice (initator) side the
-private and public keys, repectively.  We likewise let $\lambda$
+private and public keys, respectively.  We likewise let $\lambda$
 and $\Lambda$ be the Bob (respondent) private and public keys. 
 % DO IT?
 Again now, $\CPK$, $\CSK$, $\LPK$, $\LSK$, $\KEX_2$ and $\KEX_3$
@@ -407,12 +407,12 @@ the Ring-LWE key exchange itself being broken because 
$\lambda_j$
 and $\Lambda_j$ are constructed using the public key $\Mu$. 
 
 First, the polynomial $a$ commonly depends upon $\Mu$, like in
-\cite{NewHope}, so unlinkability explicity depends upon the Ring-LWE
+\cite{NewHope}, so unlinkability explicitly depends upon the Ring-LWE
 problem\cite{}.  [[ PROOF ??? ]]
 
 Second, the reconciliation information in $\Lambda$ might leak
 additional information about $\lambda$.  
-[[ LITTERATURE ADDRESSES THIS POINT ??? ]]
+[[ LITERATURE ADDRESSES THIS POINT ??? ]]
 
 Ring-LWE key exchanges require that both Alice and Bob's keys be
 ephemeral because the success or failure of the key exchange
@@ -423,7 +423,7 @@ schemes\cite{??RLWEsig??}, and this situation impacts us as 
well.
 A Taler wallet should control both sides during the refresh protocol,
  which produces an interesting connundrum.
 An honest wallet could ensure that the key exchange always succeeds.
-If wallets were honest, then one could tune the Ring-LWE paramaters
+If wallets were honest, then one could tune the Ring-LWE parameters
 to leave the probability of failure rather high,
  saving the exchange bandwidth, storage, and verification time.
 A dishonest wallet and merchant could conversely search the key space
@@ -432,25 +432,25 @@ merchant in tax evasion.
 
 [[ IS THE FOLLOWING IMPOSSIBLE ??? ]]
 
-If possible, we should  tune the Ring-LWE paramaters to reduce costs
+If possible, we should  tune the Ring-LWE parameters to reduce costs
 to the exchange, and boost the unlinkability for the users, while 
 simultaniously
 
 % \smallskip
 % \subsection{Comparson}
 
-At present, the SIDH implemention in \cite{SIDH16} requires about
+At present, the SIDH implementation in \cite{SIDH16} requires about
 one third the key material and 100?? times as much CPU time as the
-Ring-LWE implemention in \cite{NewHope}.
+Ring-LWE implementation in \cite{NewHope}.
 [[ We believe this provides a strong reason to continue exploring 
-paramater choices for Ring-LWE key exchange along with protocol tweaks.  
+parameter choices for Ring-LWE key exchange along with protocol tweaks.  
 ... ]]
 
 
 \section{Hashed-based one-sided public keys}
 
 We now define our hash-based encryption scheme.
-Let $\delta$ denote our query security paramater and
+Let $\delta$ denote our query security parameter and
  let $\mu$ be a bit string.
 For $j \le \kappa$, we define a Merkle tree $T_j$ of height $\delta$
 with leaves $\eta_j = H(\mu || "YeyCoins!" || t || j)$
@@ -500,8 +500,8 @@ an attacker to pursue $\eta_j$ alone unless they expect to 
break
 curve25519 in the future, either through mathematical advances or
 by building a quantum computer.  
 
-We therefore view $\delta$ as a query complexity paramater whose 
-optimial setting depends upo nthe strength of the overall protocoll. 
+We therefore view $\delta$ as a query complexity parameter whose 
+optimial setting depends upo nthe strength of the overall protocol. 
 
 \smallskip
 
@@ -510,7 +510,7 @@ We can magnify the effective $\delta$ by using multiple 
$\eta_j$.
 ... analysis ...
 % multiple withdrawals
 
-We believe this provides sufficent post-quantum security for
+We believe this provides sufficient post-quantum security for
 refreshing change.  
 
 
@@ -518,11 +518,11 @@ refreshing change.
 
 We noted in \S\ref{subsec:withdrawal} above that exchange might
 require that initial withdrawals employs a refresh-like operation.
-In this scenarion, we refresh from a pseudo-coin $(C,\Mu)$ where
+In this scenario, we refresh from a pseudo-coin $(C,\Mu)$ where
  $C$ is the user's reserve key \cite[??]{Taler} and
  $\Mu$ s a post-quantum public key kept with $C$.
 As a result, our hash-based scheme should increase the security
-paramater $\delta$ to allow a query for every  withdrawal operation.
+parameter $\delta$ to allow a query for every  withdrawal operation.
 
 Instead, ...
 [[ ??? we propose using a Merkle tree of Alice side Ring-LWE keys,
@@ -565,7 +565,7 @@ Crazy pants ideas :
 
 Use a larger Mrkle tree with start points seeded throughout 
 
-Use a Merkle tree of SWIFFT hash functions becuase
+Use a Merkle tree of SWIFFT hash functions because
  their additive homomorphic property lets you keep the form of a polynomial
 
 
diff --git a/doc/paper/taler.bib b/doc/paper/taler.bib
index a46c9384..14b57092 100644
--- a/doc/paper/taler.bib
+++ b/doc/paper/taler.bib
@@ -413,7 +413,7 @@ issn="1432-1378",
   volume="16",
   number="3",
   pages="185--215",
-  abstract="We introduce a new class of computational problems which we call 
the ``one-more-RSA-inversion'' problems. Our main result is that two problems 
in this class, which we call the chosen-target and known-target inversion 
problems, respectively, have polynomially equivalent computational complexity. 
We show how this leads to a proof of security for Chaum's RSA-based blind 
signature scheme in the random oracle model based on the assumed hardness of 
either of these problems. We defi [...]
+  abstract="We introduce a new class of computational problems which we call 
the ``one-more-RSA-inversion'' problems. Our main result is that two problems 
in this class, which we call the chosen-target and known-target inversion 
problems, respectively, have polynomially equivalent computational complexity. 
We show how this leads to a proof of security for Chaum's RSA-based blind 
signature scheme in the random oracle model based on the assumed hardness of 
either of these problems. We defi [...]
   issn="1432-1378",
   doi="10.1007/s00145-002-0120-1",
   doi_url="http://dx.doi.org/10.1007/s00145-002-0120-1";,
diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex
index e1a120c9..45eeacdf 100644
--- a/doc/paper/taler.tex
+++ b/doc/paper/taler.tex
@@ -1243,7 +1243,7 @@ certification process.
 We assume the exchange operates honestly when discussing taxability.
 We feel this assumption is warranted mostly because a Taler exchange
 requires licenses to operate as a financial institution, which it
-risks loosing if it knowingly facilitates tax evasion.
+risks losing if it knowingly facilitates tax evasion.
 We also expect an auditor monitors the exchange similarly to how
 government regulators monitor financial institutions.
 In fact, our auditor software component gives the auditor read access
@@ -1772,7 +1772,7 @@ currency.  A tax auditor can then request the merchant to 
reveal
 (meaningful) details about the business transaction ($\mathcal{D}$,
 $a$, $p$, $r$), including proof that applicable taxes were paid.
 
-If a merchant is not able to provide theses values, they can be
+If a merchant is not able to provide these values, they can be
 subjected to financial penalties by the state in relation to the
 amount transferred by the traditional currency transfer.
 
diff --git a/doc/paper/taler_FC2016.txt b/doc/paper/taler_FC2016.txt
index 80e590c3..176e9c75 100644
--- a/doc/paper/taler_FC2016.txt
+++ b/doc/paper/taler_FC2016.txt
@@ -118,7 +118,7 @@ is less a currency and more an open protocol for creating 
new
 currencies. So what? And why do altcoins become a ponzi scheme? (Noting
 that you do not say that they might become one, rather that they do).
 
-> We have adjusted that langauge, as some like Dogecoin have removed
+> We have adjusted that language, as some like Dogecoin have removed
 > the 21 billion BTC cap to reduce the ponzi-like tendencies.  
 > There remains a large trend towards ponzi schemes in the altcoin
 > world however, amusingly noted by https://ponzico.win/ and 
@@ -307,7 +307,7 @@ scheme suggests that a any transfers of value should be 
taxed. However,
 the issuing protocol in 4.1 can be abused to transfer a coin, without
 paying tax, and in an unlikable manner.
 
-> Technically 4.1 is not transfering a coin, as it is issuing a coin.
+> Technically 4.1 is not transferring a coin, as it is issuing a coin.
 > Again, the loophole is/was discussed in the paper.
 
 The party withdrawing the coin
diff --git a/doc/paper/taler_FC2017.txt b/doc/paper/taler_FC2017.txt
index 66f8560a..f66530c6 100644
--- a/doc/paper/taler_FC2017.txt
+++ b/doc/paper/taler_FC2017.txt
@@ -220,11 +220,11 @@ wanting this features is that it enables refunds from a 
merchant that
 later can be refreshed into "clean" coins that are unlinkable to the
 refunded coins. The protocol is based on what appears to be a standard
 cut-and-choose approach, which does not appear to be particularly
-novel. On the postive side, the problem appears a natural and if it
+novel. On the positive side, the problem appears a natural and if it
 hasn't been done before certainly useful. On the negative side, since
 the paper does not contain any formal definitions, or even semi-formal
 specifications of the desiderata, it is very hard to understand what
-actually is acheived. Furthermore, no proofs of security are given,
+actually is achieved. Furthermore, no proofs of security are given,
 and even the protocol is hard to fully understand. As such, I would
 suggest the authors to first formalize their approach and
 resubmitting.
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 deterren [...]
+  \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 [...]
   \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
diff --git a/src/auditor/report-lib.c b/src/auditor/report-lib.c
index 4aa8b45b..f946de52 100644
--- a/src/auditor/report-lib.c
+++ b/src/auditor/report-lib.c
@@ -572,7 +572,7 @@ TALER_ARL_amount_subtract_ (struct TALER_Amount *diff,
 /**
  * Perform subtraction of amounts. Negative results should be signalled by the
  * return value (leaving @a diff set to 'invalid'). If the subtraction fails
- * for other reasons (currency missmatch, normalization failure), logs a
+ * for other reasons (currency mismatch, normalization failure), logs a
  * detailed error and calls exit() to terminate the process (!).
  *
  * Do not call this function directly, use #TALER_ARL_amount_subtract_neg().
diff --git a/src/auditor/report-lib.h b/src/auditor/report-lib.h
index 7ae30825..0842f915 100644
--- a/src/auditor/report-lib.h
+++ b/src/auditor/report-lib.h
@@ -247,7 +247,7 @@ enum TALER_ARL_SubtractionResult
 /**
  * Perform subtraction of amounts. Negative results should be signalled by the
  * return value (leaving @a diff set to 'invalid'). If the subtraction fails
- * for other reasons (currency missmatch, normalization failure), logs a
+ * for other reasons (currency mismatch, normalization failure), logs a
  * detailed error and calls exit() to terminate the process (!).
  *
  * Do not call this function directly, use #TALER_ARL_amount_subtract_neg().
@@ -274,7 +274,7 @@ TALER_ARL_amount_subtract_neg_ (struct TALER_Amount *diff,
 /**
  * Perform subtraction of amounts.  Negative results should be signalled by
  * the return value (leaving @a diff set to 'invalid'). If the subtraction
- * fails for other reasons (currency missmatch, normalization failure), logs a
+ * fails for other reasons (currency mismatch, normalization failure), logs a
  * detailed error and calls exit() to terminate the process (!).
  *
  * @param[out] diff where to store (@a a1 - @a a2)
diff --git a/src/exchange/test_taler_exchange_httpd.conf 
b/src/exchange/test_taler_exchange_httpd.conf
index e7f763e7..23307cd2 100644
--- a/src/exchange/test_taler_exchange_httpd.conf
+++ b/src/exchange/test_taler_exchange_httpd.conf
@@ -1,5 +1,5 @@
 [PATHS]
-# Persistant data storage for the testcase
+# Persistent data storage for the testcase
 TALER_TEST_HOME = test_taler_exchange_httpd_home/
 
 [taler]
@@ -76,7 +76,7 @@ WIRE_GATEWAY_URL = "http://localhost:8082/3/";
 
 # Wire fees are specified by wire method
 [fees-x-taler-bank]
-# Fees for the forseeable future...
+# Fees for the foreseeable future...
 # If you see this after 2018, update to match the next 10 years...
 WIRE-FEE-2018 = EUR:0.01
 WIRE-FEE-2019 = EUR:0.01
diff --git a/src/exchangedb/test_exchangedb.c b/src/exchangedb/test_exchangedb.c
index c9b5c6ce..83d75b29 100644
--- a/src/exchangedb/test_exchangedb.c
+++ b/src/exchangedb/test_exchangedb.c
@@ -191,7 +191,7 @@ struct DenomKeyPair
 /**
  * Destroy a denomination key pair.  The key is not necessarily removed from 
the DB.
  *
- * @param dkp the keypair to destroy
+ * @param dkp the key pair to destroy
  */
 static void
 destroy_denom_key_pair (struct DenomKeyPair *dkp)
diff --git a/src/include/taler_auditor_service.h 
b/src/include/taler_auditor_service.h
index 27959a88..e7f056e5 100644
--- a/src/include/taler_auditor_service.h
+++ b/src/include/taler_auditor_service.h
@@ -309,7 +309,7 @@ struct TALER_AUDITOR_ExchangeInfo
 
 
 /**
- * Function called with the result from /exchagnes.
+ * Function called with the result from /exchanges.
  *
  * @param cls closure
  * @param hr HTTP response data
diff --git a/src/include/taler_mhd_lib.h b/src/include/taler_mhd_lib.h
index 8cfb8072..4b34f41d 100644
--- a/src/include/taler_mhd_lib.h
+++ b/src/include/taler_mhd_lib.h
@@ -330,7 +330,7 @@ TALER_MHD_parse_json_array (struct MHD_Connection 
*connection,
 
 
 /**
- * Extraxt fixed-size base32crockford encoded data from request.
+ * Extract fixed-size base32crockford encoded data from request.
  *
  * Queues an error response to the connection if the parameter is missing or
  * invalid.
diff --git a/src/lib/exchange_api_handle.c b/src/lib/exchange_api_handle.c
index b12e88a2..75b63abc 100644
--- a/src/lib/exchange_api_handle.c
+++ b/src/lib/exchange_api_handle.c
@@ -1499,7 +1499,7 @@ parse_date_string (const char *date,
 /**
  * Function called for each header in the HTTP /keys response.
  * Finds the "Expire:" header and parses it, storing the result
- * in the "expire" field fo the keys request.
+ * in the "expire" field of the keys request.
  *
  * @param buffer header data received
  * @param size size of an item in @a buffer
diff --git a/src/testing/test_exchange_api_twisted.c 
b/src/testing/test_exchange_api_twisted.c
index 25cee058..0b8de5b9 100644
--- a/src/testing/test_exchange_api_twisted.c
+++ b/src/testing/test_exchange_api_twisted.c
@@ -153,8 +153,7 @@ run (void *cls,
    * NOTE: not all CMDs actually need the twister,
    * so it may be better to move those into the "main"
    * lib test suite.
-   */
-  struct TALER_TESTING_Command refund[] = {
+   */struct TALER_TESTING_Command refund[] = {
     CMD_TRANSFER_TO_EXCHANGE ("create-reserve-r1",
                               "EUR:5.01"),
     CMD_EXEC_WIREWATCH ("wirewatch-r1"),
diff --git a/src/testing/test_exchange_api_twisted.conf 
b/src/testing/test_exchange_api_twisted.conf
index f93fe912..3f5b6f88 100644
--- a/src/testing/test_exchange_api_twisted.conf
+++ b/src/testing/test_exchange_api_twisted.conf
@@ -2,7 +2,7 @@
 #
 
 [PATHS]
-# Persistant data storage for the testcase
+# Persistent data storage for the testcase
 TALER_TEST_HOME = test_exchange_api_home/
 
 
@@ -109,7 +109,7 @@ UNIX_MATCH_GID = YES
 
 
 [fees-x-taler-bank]
-# Fees for the forseeable future...
+# Fees for the foreseeable future...
 # If you see this after 2017, update to match the next 10 years...
 WIRE-FEE-2018 = EUR:0.01
 WIRE-FEE-2019 = EUR:0.01
diff --git a/src/testing/testing_api_cmd_serialize_keys.c 
b/src/testing/testing_api_cmd_serialize_keys.c
index aa39b8a3..82df0f06 100644
--- a/src/testing/testing_api_cmd_serialize_keys.c
+++ b/src/testing/testing_api_cmd_serialize_keys.c
@@ -39,7 +39,7 @@ struct SerializeKeysState
   /**
    * Exchange URL.  Needed because the exchange gets disconnected
    * from, after keys serialization.  This value is then needed by
-   * subsequent commands that have to reconnect to the exchagne.
+   * subsequent commands that have to reconnect to the exchange.
    */
   char *exchange_url;
 };

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]