Use volatility for setting buyers security deposit

[ManfredKarrer]

After the discussion how to communicate the concept of the buyers security deposit to the user (#1216) I think best would be that we set the deposit based on volatility and remove the option that the user can set it completely.
Giving the user too many options means work (learning the context) and distracts from the core task of trading. It is also hard to estimate for a user what a good value for the deposit would be.
I think it is better that we deliver a volatility index from the provider nodes and based on that we set the buyers deposit.
The volatility can be measured by the price nodes as they get the prices for all currencies anyway.
For the very few currencies where we don't have a market price we can use the latest Bisq price or set a default.

[ripcurlx]

The only question that still needs to be answered is how we communicate trust to first-time users, so there is no need for providing super low buyer security deposits. I'm not sure if we do have this use-case atm anyways. I think we need to make it as easy as possible for the user to purchase their first amount of BTC without existing BTC off Bisq (or even better within Bisq 😄 ). If we enable the user to purchase BTC without BTC I think it doesn't matter so much if the security deposit is 0.01 BTC ($85.82) or 0.0005 BTC ($4.29) IMO. We can communicate trust in the platform in other ways as well (amount of volume, # of trades completed, reputation/risk profile of traders,...)

[ManfredKarrer]

You mean the old "how to buy the first BTC" problem? i would keep that out here as that is a larger issue. Even if we ignore the security risks it would require quite a lot of effort of trade protocol changes, so I don't see that realistic in near/mid term future.

To keep the deposit small for low value trades (test trades) we can use a non linear function. E.g. For small amounts the sec. deposit is smaller (e.g. 1% of trade amount) than for larger amounts (e.g. 5% of trade amount).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ManfredKarrer]

Still relevant

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. Feel free to reopen it if you think it is still relevant.