gnunet-svn
[Top][All Lists]

## [taler-wallet-core] branch master updated: fix more typos

 From: gnunet Subject: [taler-wallet-core] branch master updated: fix more typos Date: Wed, 28 Apr 2021 00:00:39 +0200

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

grothoff pushed a commit to branch master
in repository wallet-core.

Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Wed Apr 28 00:00:37 2021 +0200

fix more typos
---
contrib/articles/spending.txt          |  6 +++---
contrib/articles/ui/figs/cc3ds.pml     |  2 +-
contrib/articles/ui/figs/taler-pay.pml |  2 +-
contrib/articles/ui/ui-outline.tex     | 10 +++++-----
contrib/articles/ui/ui.tex             |  6 +++---
contrib/articles/ui/ui_short.tex       |  4 ++--
7 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/contrib/articles/spending.txt b/contrib/articles/spending.txt
index 3919117b..7f2c716f 100644
--- 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
index 2a2ba3c1..66f9dbdd 100644
--- 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
index 93b21f85..e33b6603 100644
--- 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

index 59a83421..ef79d91b 100644
@@ -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
index ba3cfd18..30c875a3 100644
--- 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
index ccf36cdf..37cd8b07 100644
--- 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
index f48dd86e..d3c6e65f 100644
--- 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

--