commit 2a619eadbe510c49e3b6a29d0813168840da998c
parent 9b89387535cce603f80c9280063ffc7641279143
Author: Christian Grothoff <christian@grothoff.org>
Date: Wed, 28 Apr 2021 00:00:37 +0200
fix more typos
Diffstat:
7 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/contrib/articles/spending.txt b/contrib/articles/spending.txt
@@ -67,7 +67,7 @@ Now there are some additional complexities related to giving change and not know
3. Integer linear programming
(It helps with understanding the greedy algorithm too)
-We almost have an integer linear program because all these functions parameterized by D are simply vectors. We just need to eliminate that annoying max(0, ), which we do by introducing a variable z. I'm going to switch from t[x] to d[x] = t[x] + p[x] and surpress the indexes [x] here since only m, c, and z lack indexes.
+We almost have an integer linear program because all these functions parameterized by D are simply vectors. We just need to eliminate that annoying max(0, ), which we do by introducing a variable z. I'm going to switch from t[x] to d[x] = t[x] + p[x] and suppress the indexes [x] here since only m, c, and z lack indexes.
Select d : D -> Z and p : D -> Z so as to minimize the function
z + sum_x ( r*p + c*(d+p) )
@@ -119,11 +119,11 @@ It's maybe now easier to visualize the greedy algorithm working when you think a
4. Smarter Greed
-If we're only allowed to spend one denomination at some price, then we shown the minium is achieved when that denomination x in D is chosen to minimize
+If we're only allowed to spend one denomination at some price, then we shown the minimum is achieved when that denomination x in D is chosen to minimize
(f[x]+c)/v[x] + (r[x]+c)/(v[x]*d[x])*p[x]
where p[x] = max(1,price mod v[x]). We could approximate this by (f[x]+c)/v[x] under several reasonable hypotheses, not unfortunately r >> f, but price >> v[x] still helps. In any case, there are many situations where minimizing (f[x]+c)/v[x] handles this single denomination spend.
-We know from our optimal substructure property that, for an optimal allocation, there is a denomination x such that zeroing out t[y], p[y], and v'[y] for y not x, and adjusting the price acordingly, gives an optimal allocation. It follows that a greedy algorithm that uses D sorted by increasing (f[x]+c)/v[x] frequently works, although not when mints charge too much for refreshes
+We know from our optimal substructure property that, for an optimal allocation, there is a denomination x such that zeroing out t[y], p[y], and v'[y] for y not x, and adjusting the price accordingly, gives an optimal allocation. It follows that a greedy algorithm that uses D sorted by increasing (f[x]+c)/v[x] frequently works, although not when mints charge too much for refreshes
Roughly this algorithm looks like:
diff --git a/contrib/articles/ui/figs/cc3ds.pml b/contrib/articles/ui/figs/cc3ds.pml
@@ -88,7 +88,7 @@ End
MPSP->CPSP: Capture
-== Fulfilment ==
+== Fulfillment ==
Payee->Payer: Provide products or services
diff --git a/contrib/articles/ui/figs/taler-pay.pml b/contrib/articles/ui/figs/taler-pay.pml
@@ -38,7 +38,7 @@ Exchange->Payee: Confirm payment
Payee->Payer: Confirm payment
-== Fulfilment ==
+== Fulfillment ==
Payer->Payee: Reload fulfillment URL for delivery
diff --git a/contrib/articles/ui/ui-cameraready.tex b/contrib/articles/ui/ui-cameraready.tex
@@ -964,7 +964,7 @@ it has the following key advantages:
% // ...
% let refundPermissions = /* ... */;
% taler.acceptRefunds(refundPermissions, (err) => {
-% alert("An error occured while attempting a refund");
+% alert("An error occurred while attempting a refund");
% });
%</script>
%\end{lstlisting}
@@ -1025,7 +1025,7 @@ anonymous payment system.
%a refund operation cannot be considered anonymous anymore because a
%merchant, and possibly the exchange, has now seen them and could
%link them that previous transaction. At best, these tainted coins
-%are only pseudononymous, similar to Bitcoin accounts.
+%are only pseudonymous, similar to Bitcoin accounts.
%
%To maintain anonymity, a Taler wallet automatically performs a
%{\em refresh} operation with the mint API to both replace tainted
@@ -1381,7 +1381,7 @@ situation.
Finally, attempts to address the scalability hudles of Bitcoin using
side-chains or schemes like BOLT introduce semi-centralized
-intermediaries, not wholey unlike Taler's use of exchanges. Compared
+intermediaries, not wholly unlike Taler's use of exchanges. Compared
to BOLT, we would expect a Taler exchange operating in BTC to offer
stronger security to all parties and stronger anonymity to customers,
as well as being vastly cheaper to operate.
diff --git a/contrib/articles/ui/ui-outline.tex b/contrib/articles/ui/ui-outline.tex
@@ -5,7 +5,7 @@
\begin{document}
-theme : Privacy increses usability
+theme : Privacy increases usability
title?
outline :
@@ -15,7 +15,7 @@ Describe workflow in existing payment systems
- Cash
- authentication at ATM
- transaction authenticated by the cash
- - worries : counterfit bills, wrong currency, etc.
+ - worries : counterfeit bills, wrong currency, etc.
- refunds
- CC authentication
- online vs offline
@@ -50,9 +50,9 @@ Taler payment process from customers prospective
- ATM
- merchant
- contract
- - digitally signed is better than paper reciept
+ - digitally signed is better than paper receipt
- failure modes
- - insufficent funds
+ - insufficient funds
- restoring from backups causes double spending
- mint gives proof
- restoring from backups can lose coins
@@ -75,7 +75,7 @@ Denomination choice
- Anonymity refresh protocol
- Withdraw automates like ATMs
-Broser extension
+Browser extension
- RESTful vs Bitcoin, OpenCoin, etc.
- Retrying RESTful transactions always works
- minimizing dialog
diff --git a/contrib/articles/ui/ui.tex b/contrib/articles/ui/ui.tex
@@ -1016,7 +1016,7 @@ it has the following key advantages:
// ...
let refundPermissions = /* ... */;
taler.acceptRefunds(refundPermissions, (err) => {
- alert("An error occured while attempting a refund");
+ alert("An error occurred while attempting a refund");
});
</script>
\end{lstlisting}
@@ -1077,7 +1077,7 @@ anonymous payment system.
%a refund operation cannot be considered anonymous anymore because a
%merchant, and possibly the exchange, has now seen them and could
%link them that previous transaction. At best, these tainted coins
-%are only pseudononymous, similar to Bitcoin accounts.
+%are only pseudonymous, similar to Bitcoin accounts.
%
%To maintain anonymity, a Taler wallet automatically performs a
%{\em refresh} operation with the mint API to both replace tainted
@@ -1433,7 +1433,7 @@ situation.
Finally, attempts to address the scalability hudles of Bitcoin using
side-chains or schemes like BOLT introduce semi-centralized
-intermediaries, not wholey unlike Taler's use of exchanges. Compared
+intermediaries, not wholly unlike Taler's use of exchanges. Compared
to BOLT, we would expect a Taler exchange operating in BTC to offer
stronger security to all parties and stronger anonymity to customers,
as well as being vastly cheaper to operate.
diff --git a/contrib/articles/ui/ui_short.tex b/contrib/articles/ui/ui_short.tex
@@ -179,14 +179,14 @@ instance of the digital contract with the opportunity to pay for it.
% if we already have the url? i.e. the non-fulfillment URL
% that just identifies the resource ...
-The case where a user already payed for a resource and then visits
+The case where a user already paid for a resource and then visits
the resource URL (instead of the fulfillment URL) after losing temporary
session state is also handled as expected, since the wallet component will
look for contracts that refer to the same resource.
While Taler is designed to work well with digital resources on the web,
it can also be used for more traditional purchases. The resource that
-is being payed for then represents the shopping cart of items that
+is being paid for then represents the shopping cart of items that
are being purchased.
%\newpage
