diff options
| -rw-r--r-- | contrib/articles/spending.txt | 6 | ||||
| -rw-r--r-- | contrib/articles/ui/figs/cc3ds.pml | 2 | ||||
| -rw-r--r-- | contrib/articles/ui/figs/taler-pay.pml | 2 | ||||
| -rw-r--r-- | contrib/articles/ui/ui-cameraready.tex | 6 | ||||
| -rw-r--r-- | contrib/articles/ui/ui-outline.tex | 10 | ||||
| -rw-r--r-- | contrib/articles/ui/ui.tex | 6 | ||||
| -rw-r--r-- | 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 3919117bc..7f2c716f8 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 2a2ba3c17..66f9dbdd4 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 93b21f856..e33b6603f 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 diff --git a/contrib/articles/ui/ui-cameraready.tex b/contrib/articles/ui/ui-cameraready.tex index 59a834212..ef79d91ba 100644 --- 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 index ba3cfd18e..30c875a3a 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 ccf36cdf9..37cd8b076 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 f48dd86e4..d3c6e65f1 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 |