taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] Exchange Fee Structure (was: Taler Android UX)


From: Christian Grothoff
Subject: Re: [Taler] Exchange Fee Structure (was: Taler Android UX)
Date: Wed, 15 Apr 2020 13:10:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

On 4/14/20 6:48 PM, Torsten Grote wrote:
> On 2020-04-13 16:56, Christian Grothoff wrote:
>>> I guess it would need a lot of malicious consumers to achieve that
>>> and imagine that one could put other defenses against that in
>>> place.
>> Tricky, due to customer's anonymity you don't really have any good
>> way to do accounting, and no good way to tell legitimate from
>> illegitimate requests. And of course we cannot simply NOT answer
>> requests either.
> 
> I don't know yet how refreshing exactly works, but could there be a
> refresh counter for coins high enough to allow legitimate use, but low
> enough to prevent abuse?

Refreshes are unlinkable, so there is no way to attach a counter. So no.

>> Well, it's of course more difficult ;-). Merchants can specify that
>> they are willing to pay certain "reasonable" wire fees. [...] But
>> imagine an exchange charges 1 EUR for wire transfers. [...] Here, the
>> merchant additionally specifies an amortization factor (a factor of
>> 40 means that the 80 cents are to be amortized over 40 customers).
>> Then, each customer would have to contribute 2 cents in wire fees.
>> But possibly not exactly 2 cents, if there is room from the deposit
>> fees...
> 
> Uff. Complicated indeed. Would be much easier without wire fees, but I
> guess you have considered that and it would run contrary to some other
> design goal.

Well, everything is much easier without fees ;-). The problem is we need
to give merchants an incentive to defer payments. Otherwise they may say
'pay me immediately' (every minute) for wire transactions of 1 cent (at
a cost of say 5 cents to the exchange). So to ensure that merchants have
an incentive to actually let exchanges batch up transactions, we must
have the possibility of exchanges charging a wire fee here.

> So as a user withdrawing money, I would want to be careful with
> exchanges charging high wire fees, because that *might* increase my fee
> with a merchant I want to pay.

Exactly.

> Maybe when showing the fees, we could hide wire fees and closing fees
> for future years when the price only increases moderately with an option
> to expand the full details.

True.

> But really, from a consumer and UX perspective, exchanges that charge
> for more than withdrawal (and maybe refresh/change) operations introduce
> so much complexity that I have a hard time imagining this being used in
> practice, especially when you compare it with the simplicity these new
> fintech apps offer. Worse: The additional complexity can be used to
> screw users over by hiding high fees in there.

In my ideal world, Taler is used for a CDBC with zero fees on
everything, except maybe refresh. And I agree that one should _strive_
for a very simple fee structure. However, if we want to ensure that an
exchange operator always has the ability to deflect certain types of
attacks by charging fees, the protocol must in principle be able to
charge fees on all expensive operations, which sadly means the wallet
must then be able to explain those fees to the user IF they are
configured by the exchange.

> So I'd say the wallet should warn about all exchanges making use of the
> fee complexity that Taler supports until there is evidence from
> practical use that the complexity is actually needed.

I'm fine with us for now setting some particularly narrow range of
"reasonable" fee structures and warn about anything "fancy".  For
example, we could say that wire fees must not increase more than 2% per
year, and then we only show the first year.

>>> Interesting. Should we maybe have little info buttons next to the
>>> fee labels with these explanations?
>> Yes. Little info buttons, but then likely jumping to walls of text
>> with the explanations ;-(.
> 
> If you want to support the full complexity and require users to
> understand it, I see no way around providing walls of text. But at least
> they are hidden by default and need to be actively opened.

"at least" - indeed.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]