[taler-docs] 01/02: Eliminating some superfluous line breaks, two little bugs

[gnunet]

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

skuegel pushed a commit to branch master
in repository docs.

commit d29a9f4512937377daa5406789eb610b6d97cfa3
Author: Stefan Kügel <skuegel@web.de>
AuthorDate: Wed Feb 3 22:12:52 2021 +0100

    Eliminating some superfluous line breaks, two little bugs
---
 design-documents/012-fee-schedule-metrics.rst | 32 +++------------------------
 1 file changed, 3 insertions(+), 29 deletions(-)

diff --git a/design-documents/012-fee-schedule-metrics.rst 
b/design-documents/012-fee-schedule-metrics.rst
index 4a9c8e8..8eb36da 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
 ---------------------------
 

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.