7 files changed, 18 insertions, 18 deletions
diff --git a/anastasis.rst b/anastasis.rst
index f7232c5..74d5160 100644
@@ -312,7 +312,7 @@ Anastasis server operators must be protected against denial-of-service attacks
where an adversary attempts to exhaust operator's resources. The API protects
against these attacks by allowing operators to set fees for all
operations. Furthermore, all data stored comes with an expiration logic, so an
-attacker cannot force servers to store data indefinitively.
+attacker cannot force servers to store data indefinitely.
A second availability issue arises from strong adversaries that may be able to
compute the account keys of some user. While we assume that such an adversary
@@ -484,7 +484,7 @@ In the following, UUID is always defined and used according to `RFC 4122`_.
:status 200 OK:
The escrow provider responds with an EncryptedRecoveryDocument_ object.
:status 304 Not modified:
- The client requested the same ressource it already knows.
+ The client requested the same resource it already knows.
:status 400 Bad request:
The $ACCOUNT_PUB is not an EdDSA public key.
:status 402 Payment Required:
diff --git a/developers-manual.rst b/developers-manual.rst
index c5f5b77..22d205f 100644
@@ -965,7 +965,7 @@ Python for Scripting
When using Python for writing small utilities, the following libraries
-* ``click`` for argument parsing (should be prefered over argparse)
+* ``click`` for argument parsing (should be preferred over argparse)
* ``pathlib`` for path manipulation (part of the standard library)
* ``subprocess`` for "shelling out" to other programs. Prefer ``subprocess.run``
over the older APIs.
@@ -1314,7 +1314,7 @@ use when talking to end users or even system administrators.
method of keeping time in :term:`GNUnet` where the time is represented
as a relative number of microseconds. Thus, a relative time specifies
- an offet or a duration, but not a date. Called relative time in
+ an offset or a duration, but not a date. Called relative time in
contrast to :term:`absolute time`.
@@ -1334,7 +1334,7 @@ use when talking to end users or even system administrators.
making a payment with :term:`coins` to a :term:`merchant`.
- Statment of an operator how they will protect the privacy of users.
+ Statement of an operator how they will protect the privacy of users.
Message that cryptographically demonstrates that a particular claim is correct.
diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst
index 1d84d45..35f5a79 100644
@@ -127,7 +127,7 @@ components:
fail to be imported due to constraint violations, this is an immediate serious
concern that must be addressed manually. The software only verifies the content
of a well-formed exchange database (well-formed with respect to SQL).
- For now, the GNU Taler reference implemenation
+ For now, the GNU Taler reference implementation
only supports Postgres, but the code could be easily extended to
support another DBMS.
@@ -387,7 +387,7 @@ the exchange operator obtains a *blob* with the data about denomination keys
that the exchange operator needs to get signed by every auditor the exchange
wishes (or is forced to) work with.
-In a normal scenario, an auditor must have some secure business proces to
+In a normal scenario, an auditor must have some secure business process to
receive the blob to sign (Website, manual delivery, ...). Note that the
blob does not contain confidential data, but signing the wrong keys would
be fatal. Given the blob, the auditor would sign it using:
@@ -596,7 +596,7 @@ Auditor implementation guide
The auditor implementation is split into five main processes, called
``taler-helper-auditor-XXX``. The split was done to realize the principle of
-least priviledge and to enable independent logic to be possibly run in
+least privilege and to enable independent logic to be possibly run in
parallel. Only the taler-wire-auditor must have (read-only) access to the
exchange's bank account, the other components only need access to the
diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst
index 6e4bae8..b156eb9 100644
@@ -914,7 +914,7 @@ TALER_SIGNATURE_AUDITOR_EXCHANGE_KEYS purpose.
The current implementation does not make provisions for secret
splitting. Still, the use of a hardware security module (HSM) for
- protecting private keys is adviseable, so please contact the
+ protecting private keys is advisable, so please contact the
developers for HSM integration support.
@@ -937,7 +937,7 @@ and clients, or only launch the parallel clients (``-m``), for example for
distributed testing over a network.
For each *parallel* (``-p``) client, a number of *reserves* (``-r``) is first established by
-**transfering** money from a "user" account (42) to the Exchange's account
+**transferring** money from a "user" account (42) to the Exchange's account
with the respective reserve public key as wire subject. Next, the
client will **withdraw** a *number of coins* (``-n``) from the reserve and
**deposit** them. Additionally, a *fraction* (``-R``) of the dirty coins will then be
diff --git a/taler-merchant-api-tutorial.rst b/taler-merchant-api-tutorial.rst
index 39cf36d..823a675 100644
@@ -377,7 +377,7 @@ are recognized in the JSON request object:
- amount: Amount that should be given to the visitor as a tip.
- instance: Merchant instance that grants the tip (each instance may
- have its own independend tipping funds configured).
+ have its own independent tipping funds configured).
- justification: Description of why the tip was granted. Human-readable
text not exposed to the customer, but used by the Back Office.
@@ -533,14 +533,14 @@ signature (``session_sig``). This signature certifies that the wallet
showed a payment receipt for the respective order in the current
-Session-bound payments are triggerd by passing the ``session_id``
+Session-bound payments are triggered by passing the ``session_id``
parameter to the ``/check-payment`` endpoint. The wallet will then
redirect to the fulfillment page, but include an additional
``session_sig`` parameter. The frontend can query ``/check-payment``
with both the ``session_id`` and the ``session_sig`` to verify that the
signature is correct.
-The last session ID that was successfuly used to prove that the payment
+The last session ID that was successfully used to prove that the payment
receipt is in the user’s wallet is also available as ``last_session_id``
in the response to ``/check-payment``.
diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst
index 6d14806..1e6e72a 100644
@@ -87,7 +87,7 @@ components:
to process financial transactions with Taler. This manual primarily
describes how to install and configure this backend.
- A DBMS which stores the transaction history for the Taler backend.
- For now, the GNU Taler reference implemenation only supports
+ For now, the GNU Taler reference implementation only supports
Postgres, but the code could be easily extended to support another
DBMS. Please review the Postgres documentation for details on
how to configure the database.
@@ -1100,7 +1100,7 @@ in a special “402 Payment Required” response inside the ``X-Taler-Tip``
The frontend should handle errors returned by the backend, such as
-missconfigured instances or a lack of remaining funds for tipping.
+misconfigured instances or a lack of remaining funds for tipping.
@@ -1336,7 +1336,7 @@ second gives the chance to leave some payments unaggregated, and also to
use merchant instances other than the default (which is, actually, the
one used by default by the tool).
-Note: the abilty of driving the aggregation policy is useful for testing
+Note: the ability of driving the aggregation policy is useful for testing
the backoffice facility.
Any subcommand is also equipped with the canonical ``--help`` option, so
@@ -1410,7 +1410,7 @@ layout:
# The exchange used during the test: make sure the merchant backend
- # being tested accpets this exchange.
+ # being tested accepts this exchange.
# If the sysadmin wants, she can also install a local exchange
# and test against it.
EXCHANGE = https://exchange.demo.taler.net/
diff --git a/taler-nfc-guide.rst b/taler-nfc-guide.rst
index 88fa13d..8143387 100644
@@ -241,7 +241,7 @@ NFC. In particular, only JSON request and response bodies are allowed.
It is currently assumed that the requests and responses fit into one APDU frame.
For devices with more limited maximum APDU sizes, additional TIDs for segmented
-tunnel requests/responsed may be defined in the future.
+tunnel requests/responses may be defined in the future.
A request for tunneling is initiated with TID ``0x03`` and responded to with
TID ``0x02`` (see tables above). A tunneling request is identified by a