From 14262aff361271fa2856910c01ac07c416574807 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sat, 31 Oct 2020 16:44:51 +0100 Subject: add fees dd to index --- design-documents/008-fees.rst | 120 ++++++++++++++++++++++++++++++++++++++++++ design-documents/fees.rst | 120 ------------------------------------------ design-documents/index.rst | 1 + 3 files changed, 121 insertions(+), 120 deletions(-) create mode 100644 design-documents/008-fees.rst delete mode 100644 design-documents/fees.rst (limited to 'design-documents') diff --git a/design-documents/008-fees.rst b/design-documents/008-fees.rst new file mode 100644 index 00000000..331d6cd7 --- /dev/null +++ b/design-documents/008-fees.rst @@ -0,0 +1,120 @@ +Design Doc 008: Fee Structure Metrics +##################################### + +.. note:: + + This design document is currently a draft, it + does not reflect any implementation decisions yet. + +Summary +======= + +We discuss criterea for evaluating an exchange's denomination and fee structure. + +Motivation +========== + +Currently, users of a Taler wallet can't easily judge the fee structure of an +exchange and what it will mean for them. Thus we want to define some metrics +that allow a user to make more informed decisions. + +Similarly, the fee structure metrics might be used by exchange operators +as a senity check. + +An auditor might also enforce ranges on these metrics as a condition for +auditing a denomination structure. + +Requirements +============ + +* Privacy: A denomination structure that has too many denominations + will result in reduced anonymity. +* Efficiency: A denomination structure that has too few denominations + is inefficient. +* Predictability: + + * The amount of fees for an operation should not come + as a total surprise for the user. + + * The user should know beforehand when they have to be online + to refresh their balance, and they should know how much + this will cost them. + +The metrics for the exchange should be advisory, i.e. an informed user should +be able to accept the withdrawal anyway. + +The exchange's business interests may be in conflict with (1) a transparency of +cost for the user and and (2) restrictions on denomination/fee structures. +Thus the metrics should still allow some degree of variability between +exchanges. + +We make the assumption that wallet always prefer operations with better +privacy. For example, a single coin should only be used for at most one +spend operation and at most one refresh operation. + +Proposed Solution +================= + +The following yes/no criteria are applied to determine if a denomination/fee structure +is *reasonable*: + +* For a denomination of value ``v``, either + + (a) ``v`` must be the the smallest offered denomination, or + (b) there must be another denomination with a value of at least ``v / 10``. + +Is there a relationship between the smallest denomination and the size of fees? + +Idea: When when only doing spends on a coin that are a multiple of the smallest spending amount, +we constrain the number of coins that are refreshed into. + +When evaluating the e2e cost of a denomiation, look at: + * the cost of withdrawing the coin by itself and spending it fully, directly + * the cost of withdrawing the coin, directly refreshing it into the next smallest + fully fitting currency (or use greedy fit!) and add up the withdraw, refresh and re-withdraw fees. + * percentage is always computed with sum against the full coin's value + * smallest coins are an exception + +Actually, smallest spendable amount should be a multiple of the smallest coins, since +we still need to deal with fees even at that level + + +Refund fees should not be higher than if the user got a refund through +a different channel than Taler and then purchased the product again. + + + +The following metrics are also defined: + +* Shortest time from withdrawal expiration to deposit expiration. +* Upkeep, i.e. how much does it cost the customer to keep coins in their wallet + per time period, on average over a long period. +* Assurance period, i.e. the time span for which the exchange has already announced + its fees. +* Spending amount range. +* End-to-end fee range. This is the minimum/maximum cost to withdraw electronic cash + (within the spending range), spend some of it and then obtain change for the transaction. +* Merchant contribution range. This is the percentage of the end-to-end fees that the merchant + can cover if they choose to do so. + + +Alternatives +============ + +* Users can manually study the fee structure. +* The auditor could impose a fee structure and not + allow any variability between exchanges + +Drawbacks +========= + +* The approach does not work well in some special-purpose deployments, + where the coin structure is tailored to the products of merchants, + and refreshing would never even happen. + +* The approach also does not consider more "creative" fee structures, + such as ones where coins that are valid for a longer time have higher + fees. + +Discussion / Q&A +================ diff --git a/design-documents/fees.rst b/design-documents/fees.rst deleted file mode 100644 index 3dabd0bb..00000000 --- a/design-documents/fees.rst +++ /dev/null @@ -1,120 +0,0 @@ -Design Doc 003: Fee Structure Metrics -##################################### - -.. note:: - - This design document is currently a draft, it - does not reflect any implementation decisions yet. - -Summary -======= - -We discuss criterea for evaluating an exchange's denomination and fee structure. - -Motivation -========== - -Currently, users of a Taler wallet can't easily judge the fee structure of an -exchange and what it will mean for them. Thus we want to define some metrics -that allow a user to make more informed decisions. - -Similarly, the fee structure metrics might be used by exchange operators -as a senity check. - -An auditor might also enforce ranges on these metrics as a condition for -auditing a denomination structure. - -Requirements -============ - -* Privacy: A denomination structure that has too many denominations - will result in reduced anonymity. -* Efficiency: A denomination structure that has too few denominations - is inefficient. -* Predictability: - - * The amount of fees for an operation should not come - as a total surprise for the user. - - * The user should know beforehand when they have to be online - to refresh their balance, and they should know how much - this will cost them. - -The metrics for the exchange should be advisory, i.e. an informed user should -be able to accept the withdrawal anyway. - -The exchange's business interests may be in conflict with (1) a transparency of -cost for the user and and (2) restrictions on denomination/fee structures. -Thus the metrics should still allow some degree of variability between -exchanges. - -We make the assumption that wallet always prefer operations with better -privacy. For example, a single coin should only be used for at most one -spend operation and at most one refresh operation. - -Proposed Solution -================= - -The following yes/no criteria are applied to determine if a denomination/fee structure -is *reasonable*: - -* For a denomination of value ``v``, either - - (a) ``v`` must be the the smallest offered denomination, or - (b) there must be another denomination with a value of at least ``v / 10``. - -Is there a relationship between the smallest denomination and the size of fees? - -Idea: When when only doing spends on a coin that are a multiple of the smallest spending amount, -we constrain the number of coins that are refreshed into. - -When evaluating the e2e cost of a denomiation, look at: - * the cost of withdrawing the coin by itself and spending it fully, directly - * the cost of withdrawing the coin, directly refreshing it into the next smallest - fully fitting currency (or use greedy fit!) and add up the withdraw, refresh and re-withdraw fees. - * percentage is always computed with sum against the full coin's value - * smallest coins are an exception - -Actually, smallest spendable amount should be a multiple of the smallest coins, since -we still need to deal with fees even at that level - - -Refund fees should not be higher than if the user got a refund through -a different channel than Taler and then purchased the product again. - - - -The following metrics are also defined: - -* Shortest time from withdrawal expiration to deposit expiration. -* Upkeep, i.e. how much does it cost the customer to keep coins in their wallet - per time period, on average over a long period. -* Assurance period, i.e. the time span for which the exchange has already announced - its fees. -* Spending amount range. -* End-to-end fee range. This is the minimum/maximum cost to withdraw electronic cash - (within the spending range), spend some of it and then obtain change for the transaction. -* Merchant contribution range. This is the percentage of the end-to-end fees that the merchant - can cover if they choose to do so. - - -Alternatives -============ - -* Users can manually study the fee structure. -* The auditor could impose a fee structure and not - allow any variability between exchanges - -Drawbacks -========= - -* The approach does not work well in some special-purpose deployments, - where the coin structure is tailored to the products of merchants, - and refreshing would never even happen. - -* The approach also does not consider more "creative" fee structures, - such as ones where coins that are valid for a longer time have higher - fees. - -Discussion / Q&A -================ diff --git a/design-documents/index.rst b/design-documents/index.rst index fda8b2e5..38825b2b 100644 --- a/design-documents/index.rst +++ b/design-documents/index.rst @@ -17,3 +17,4 @@ and protocol. 005-wallet-backup-sync 006-anastasis-ux 007-payment + 008-fees -- cgit v1.2.3