From d29a9f4512937377daa5406789eb610b6d97cfa3 Mon Sep 17 00:00:00 2001 From: Stefan Kügel Date: Wed, 3 Feb 2021 22:12:52 +0100 Subject: Eliminating some superfluous line breaks, two little bugs --- design-documents/012-fee-schedule-metrics.rst | 32 +++------------------------ 1 file changed, 3 insertions(+), 29 deletions(-) (limited to 'design-documents') diff --git a/design-documents/012-fee-schedule-metrics.rst b/design-documents/012-fee-schedule-metrics.rst index 4a9c8e84..8eb36da7 100644 --- a/design-documents/012-fee-schedule-metrics.rst +++ b/design-documents/012-fee-schedule-metrics.rst @@ -13,7 +13,6 @@ structure of an Exchange from different points of view (Exchange operators, buyers/users, and sellers/merchants). - Background ========== @@ -60,7 +59,7 @@ The protocol does not allow retroactive changes for denomination keys that have already been announced. This protects buyers against fee hikes for coins they already withdrew. Additionally, the **wire** and **closing** fees that apply per wire transfer must be configured for each wire method. These -fees are typcially defined per calendar year. +fees are typically defined per calendar year. For deposit, withdraw, refresh and refund operations, fees are charged per coin. The number of coins per operation increases logarithmically with the @@ -129,7 +128,7 @@ conflicting criteria: run transactions to increase transaction costs at the Exchange or to impact availability for normal users. The most effective operation for such attacks are refresh operations, especially if those do not have a fee. -* From a marketing perspective, it is unwise if buyers see fees. +* From a marketing perspective, it is unwise that buyers see fees. In particular, **withdraw** fees are likely to be the biggest deterrent as they appear before the buyer actually uses the system to make a payment. Only **deposit** and **wire** fees can be made "invisible" to buyers @@ -184,7 +183,6 @@ exchange differs: the Exchange operators or sellers. Nevertheless, the Exchange operator could introduce a **closing** fee to cover such costs. - We now consider each of the fee types, viewed from the perspective of the buyer, the Exchange operator, and the seller, in detail. @@ -210,7 +208,6 @@ bandwidth demands as well as **refresh** fees. Thus, there does not seem to be a need to provide an additional incentive in the form of **withdraw** fees here. - **Withdraw** fee for the Exchange operator -------------------------------------------- @@ -223,7 +220,6 @@ fees, consumers may choose to hoard digital cash, which may create a legal and (negative) interest liability for the operator. Introducing a **withdraw** fee may help an Exchange operator collect revenue up-front. - **Withdraw** fee for sellers ------------------------------ @@ -232,11 +228,9 @@ a psychological barrier for their buyers to use Taler. Sellers may thus prefer to include the costs of generating coins in their selling prices and hide this cost from buyers. - **Deposit** fee for buyers -------------------------- - **Deposit** fees are split between buyer and seller, the seller offering to cover a certain total amount in fees (as part of the commercial offer) and the buyer having to cover the remaining amount in full. It is expected that @@ -247,7 +241,6 @@ for buyers if they choose an expensive Exchange operator. Deposit fees are thus a good candidate to cover all or most expenses that Exchange operators have to bear. - **Deposit** fee for Exchange operators -------------------------------------- @@ -260,20 +253,18 @@ wire transfers to happen rarely (like once per year). Thus, an Exchange operator that wants regular income from regular users must charge either **deposit** or **withdraw** fees. - **Deposit** fee for sellers --------------------------- As an Exchange operator could charge high **deposit** fees, sellers can protect themselves against excessive fees by refusing to cover fees. Sellers -determine the default maximum amount want to bear by setting the variable +determine the default maximum amount they want to bear by setting the variable ``default_max_deposit_fee``. This default can be overridden on a per-purchase basis. **Deposit** fees exceeding this maximum are borne by the buyer. Sellers are expected to cover **deposit** fees to a similar degree that they cover such expenses with other payment systems. - **Refresh** fee for buyers -------------------------- @@ -297,7 +288,6 @@ about negative interest rates. We expect that they will often not understand when or why it is charged, especially since fees for getting change are very uncommon in other payment systems. - **Refresh** fee for Exchange operators -------------------------------------- @@ -307,13 +297,11 @@ or to cover these costs with another type of fee. Using the **refresh** fee to cover costs means that the originators of excessive refreshes requests also bear their excessive cost. - **Refresh** fee for sellers --------------------------- Refresh operations do not directly affect sellers. - **Refund** fee for buyers ------------------------- @@ -332,8 +320,6 @@ Given that buyers would likely perceive it as unfair if they have to pay the **refund** fee, we generally recommend that Exchange operators should simply avoid using **refund** fees. - - **Refund** fee for Exchange operators ------------------------------------- @@ -352,7 +338,6 @@ abuse would have to happen to a degree that can basically be categorized as a denial-of-service attack, giving the exchange operator a legal argument for refusing to continue to do business with the abusive seller. - **Refund** fee for sellers -------------------------- @@ -369,8 +354,6 @@ when charging **refund** fees, as this may create probems for retailers that are legally obliged to refund 100% of the buyer's expenses (including banking costs). - - **Wire** fee for buyers ----------------------- @@ -387,8 +370,6 @@ charge competitive rates, and sellers are likely to be happy to cover the entire **wire** fee. Thus, **wire** fees should in practice rarely matter for buyers. - - **Wire** fee for Exchange operators ----------------------------------- @@ -411,8 +392,6 @@ as they need it for their business and want to afford the fee for it. Thus, setting **wire** fees slightly above operational costs for wire transfers should result in an optimal wire transfer frequency. - - **Wire** fee for sellers ------------------------ @@ -424,7 +403,6 @@ costs due to the **wire** fee or forego liquidity. However, as **wire** fees are expected to be relatively low, sellers are likely to primarily set their aggregation periods based on the needs for refunds. - **Closing** fee for buyers -------------------------- @@ -441,7 +419,6 @@ to depend on income from such a fee, and not having a **closing** fee will simplify the terms of service and could be a cheap way to produce or maintain consumer goodwill. - **Closing** fee for Exchange operators -------------------------------------- @@ -456,7 +433,6 @@ not be a problem: malicious parties wiring funds to the Exchange to trigger **closing** operations would need to have spare liquidiy, would still have to cover their own banking costs, and would also be easily identified. - **Closing** fee for sellers --------------------------- @@ -466,7 +442,6 @@ The **closing** fee does not affect sellers in any way. Proposed Solution ================= - Fee levels if abuse is low -------------------------- @@ -500,7 +475,6 @@ This fee structure becomes problematic if attackers begin to abuse it, say by excessively refreshing coins or constantly depositing and refunding the same coin. - Fee levels in case of abuse --------------------------- -- cgit v1.2.3