commit 14262aff361271fa2856910c01ac07c416574807
parent 4e29dbba2a41cbb266891c3abacb77eebddd7c08
Author: Christian Grothoff <christian@grothoff.org>
Date: Sat, 31 Oct 2020 16:44:51 +0100
add fees dd to index
Diffstat:
3 files changed, 121 insertions(+), 120 deletions(-)
diff --git a/design-documents/008-fees.rst 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
@@ -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
@@ -17,3 +17,4 @@ and protocol.
005-wallet-backup-sync
006-anastasis-ux
007-payment
+ 008-fees
