[bisq-network/proposals] Delay payout for Fiat trades if buyers account is fresh (#77)

[Manfred Karrer]

It basically added an optional phase to the trade process (payout delay). We did not really want to add new optional trade period step but packing it into the last trade step is also not really correct.  
One of the extra edge cases was how to handle the case when during the payout delay the buyers account get attested so that the delay could gets removed, but then the other peer need to know that as well. It could be known in advance (but not in all cases as SEPA has already 6 days + 30 days delay) but it would add more confustion to users why in certain circumstances the delay is not 30 days but shorter.... It also required a new message to be sent to the buyer once the seller confirmed receipt as that is the moment when the delay starts. 
It required an extra tolerance time after the delay is over for releasing the btc. I would expect many disputes here as sellers might forget after 30 days and have less incentive (deposit). So 2 days seems the min. tolerance time here to avoid too many issues with disputes.

So all in all it makes the trade process much more cumbersome and complicate from an UX perspective. All is doable but I have the feeling that this approach might not be the best.

As the delay will be a considerable drawback for both traders anyway it is questionable if they will trade much at all. I expect basically that optimal strategy for a new user:
- Do a sell trade with an authorized user to get the attestation started (no wait time as buyer is unrestricted) or a 0.01 BTC buy trade. 
- Repeat above as often wanted.
- Trade without restrictions after 30 days.

So it might be that all that implementation effort is for a very small group of users who would either be in a hurry to buy BTC or who do not mind the waiting. But then they still need a counterparty who is willing to wait as well and do the extra work with the final release of the BTC and risking to lose his seller deposit in case he forgets.
Not sure if there are really so many users who are willing to do that (both sides). And if not we have put a lot of effort for little benefit.

Costs:
- dev effort
- added risk for bugs
- added complexity will make any future change more difficult
- higher  risks for disputes if seller forgets. 
- bad user experience might lead to negative PR
- higher prices of sellers might lead to negative PR ("Bisq is expensive")

The alternative approach would be:
- New users are restricted to 0.01 BTC if they are buyer
- Once they have traded with a authorized trader the 1 months waiting starts until they get attested.
- After that they are unrestricted

So instead the extra protection with the delay we use the trade limit. As we want that anyway to allow users to try out Bisq (implemented with todays release), we might just skip the delay part at all. The small trade limit is much easier and we have that amount limit anyway - just with higher amounts (0.0625 BTC instead of 0.01 BTC -  if BTC goes to 20K again thats anyway not so small)...

So the users who would suffer from that alternative approach (compared to the delayed payout approach) would have that profile:
- They dont care so much about the delay but want to buy quickly relative big amounts with few trades (they can also do multiple trades with the 0.01 BTC limit to buy bigger amounts). 
- They are willing to pay a considerable higher price as sellers who are accepting such newbies will take higher risk for losing their security deposit as well have the added inconvenience of the delay. 

As said I am not sure how many users would fall into that profile. 

Security-wise we don't change to the delayed approach.
The "demo" mode with 0.01 BTC trades and no delay was part of the proposal anyway. I don't consider that a critical risk as well we can lower that amount if we would see that it gets abused.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/77#issuecomment-489200973
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20190503/f29c72c6/attachment-0001.html>