diff options
Diffstat (limited to 'doc/system')
| -rw-r--r-- | doc/system/conclusions.tex | 2 | ||||
| -rw-r--r-- | doc/system/introduction.tex | 2 | ||||
| -rw-r--r-- | doc/system/taler/design.tex | 10 | ||||
| -rw-r--r-- | doc/system/taler/implementation.tex | 4 | ||||
| -rw-r--r-- | doc/system/taler/security.tex | 4 |
5 files changed, 11 insertions, 11 deletions
diff --git a/doc/system/conclusions.tex b/doc/system/conclusions.tex index 1f72285fb..84c78452c 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 ba1da7083..9604f056a 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 de91daa13..c9e45f9b3 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 4b095b779..b49763c65 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 99c8e0520..cf0128a0c 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 |