[taler-docs] branch master updated: Editing the sub chapter 'Fee levels in case of misuse'

[gnunet]

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

skuegel pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 5d8ac9d  Editing the sub chapter 'Fee levels in case of misuse'
5d8ac9d is described below

commit 5d8ac9d027b2d16eff68e7bd447c6c7b6f1d11e7
Author: Stefan Kügel <skuegel@web.de>
AuthorDate: Sat Jan 16 11:08:39 2021 +0100

    Editing the sub chapter 'Fee levels in case of misuse'
---
 design-documents/012-fee-schedule-metrics.rst | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/design-documents/012-fee-schedule-metrics.rst 
b/design-documents/012-fee-schedule-metrics.rst
index e788597..f7a6f4e 100644
--- a/design-documents/012-fee-schedule-metrics.rst
+++ b/design-documents/012-fee-schedule-metrics.rst
@@ -185,10 +185,13 @@ However, refresh transactions can be triggered 
anonymously an unlimited number o
 
 * Abuse due to ``deposit transactions`` is unlikely as the Exchange operator 
will usually charge deposit fees on every denomination to generate income 
respectively to cover costs.
 
-* Abuse due to ``refresh transactions`` is possible and requires a 
differentiated treatment: The normal case for refresh operations is given, when 
wallets obtain fresh coins for a used coin of higher denomination than the 
amount to be paid. In this case, an Exchange operator will not charge a refresh 
fee on payments with coins of unsuitable denomination. Only in the case of 
abuse the Exchange operator must charge this fee when a malicious party 
triggers refreshes en masse. These misuse c [...]
-(1.) arbitrary transaction aborts;
-(2.) arbitrary repeated refunds (which, however, must be triggered by 
malicious sellers - costs are borne on a case-by-case basis).
-In extreme cases of abuse - when an exchange suffers from arbitrarily 
triggered refresh transactions, the Exchange operator must set the refresh fee 
or increase it and thus charge all coin owners whose coins were signed by that 
exchange.
+* Abuse due to ``refresh transactions`` is possible and requires a 
differentiated treatment: The normal case for refresh transactions is given 
anytime when wallets obtain fresh coins as change for a spent coin of higher 
denomination than the amount to be paid. In this case, an Exchange operator 
will not charge a fee on refreshes for payments with coins of unsuitable 
denomination. Only in the case of abuse - when an exchange suffers from 
arbitrarily triggered refresh transactions en masse [...]
+1. arbitrary transaction aborts;
+2. arbitrary repeated refunds (which, however, must be triggered by malicious 
sellers - costs are borne on a case-by-case basis by sellers).
+
+* Abuse due to ``refund transactions`` is theoretically possible and can be 
treated by introducing or increasing the 'Refund' fee whenever a seller 
triggers the refund transaction.
+
+* Abuse due to ``wire transfers`` will only be a burden for an Exchange 
operator when sellers increase the frequency of aggregated wire transfers from 
the exchange to their banking accounts. This is the case for extremely often 
triggered wire transfers after customers' deposit transactions in order to 
receive sales revenues immediately. A good reason to do this may be the 
seller's need for liquidity. Some merchants might also gain profit from 
interest rates, if they receive revues long t [...]
 
 * Abuse due to ``closing transactions`` and the involved remittances 
(withdrawing to the wallet failed within the given time frame, Exchange has to 
wire the value to the originating account) burdens the Exchange operator with 
costs for wire transfers; to prevent this, the Exchange operator can introduce 
a fee by adjusting the **closing** variable.
 

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