[bisq-network/proposals] Improve support and prioritize bug fixes in trade process (#130)

Mon Oct 28 02:03:40 UTC 2019

> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://docs.bisq.network/proposals.html)._

## Overview
I got some feedback from the arbitrators and add some conclusions what we should do to fix the most common problems.

With the new trade protocol the arbitrator takes more risk (volatility, prefunding payouts) so we need to ensure that arbitration cases go to close zero. Currently most cases are bugs and we need to eliminate those.

Beside that, we need to improve the support for Bisq users. Currently there are too many channels (Forum, GH, Slack, Keybase, Reddit, Twitter,...) and there is no coordination and its more or less random if/when someone try to help a user. There is also no training for people who do support and not all anwers are correct (but it was getting much better over the last months). 
For the case that dispute messages do not arrive we need a secondary channel for mediators/arbitrators. Currently arbitratos are not sufficiently scanning all the channels (understandably as its too much). This communication channel should be private by default (maybe keybase) and easy to use (pgp is not easy for all users unfortunately).

We should try to get to the quality of procfessional support systems with a ticket system and a dedicated support agents. We should check if such support ticket systems are compatible with Bisq (FOSS, privacy,...) and if so we should try to find a contributor who has already experience to lead that support area. We should find at least 3 support agents and provide some training and documentations about most common issues. Such FAQ/manual could be used also to delegate problem resolution to users.

Here is a summary from the feedback of the arbitrators and some comments.

### Feedback from arb2
#### Reasons for disputes:
1. (50%) Bugs with tx not published. Seems to be more problematic in times when BTC price is volatile (fees are changing fast) but might be also just subjective impression as more trades happen if BTC is volatile
2. (20%) Buyer not starting payment if BTC price changes too much ("future trade"). Happens with low trade amount and low security deposit. 
3. (15-20%) Banking problems. Slow banks tx, bank account closed. Revolut payment problems.
4. (5-10%) Missed messages: Both dispute messages and payment started message. Is better since 1.1.6
5. Some users seem to not find/see the disputes. Very few
6. User trying to cheat. Nearly no cases

#### Comments:
##### Regarding 1:
We need to work on the tx not published bug. It seems it is caused by bugs in the management of the AddressEntries. In some edge cases the meta data attached to addresses seem to get out of sync and that likely causes those issues. I suspect it happens if a take offer attempt failed or if a user is canceling an offer an create a new one.

Another problem can be too low miner fees in times of volatility. Improving the fee estimation service is a open task open since ages. We should get this done now. It is a low hanging fruit which does not requier Bisq or Java knowledge but Bitcoin knowledge. There are some services out which might be used. There is an open issue or proposal for that task with more details.

It can be that it is a broadcast problem but I doubt that it is a BitcoinJ internal issue. But we should check if in such cases there are logs indicating that the tx was not accepted by the network for some reason. 
@wiz brought up the idea that the peer is publishing as well the trade fee tx of the other peer. This might be an option but might also have unwanted side effects on the peers wallet side as BitcoinJ is not intended to handle foreign txs. The peers tx is not related to our wallet/addresses, if we commit it to our wallet it might end up in the tx list in the UI causing confusion (we would need to filter it out) and as no funds entered or left our wallet with that tx it will not have a confidence attached (not known why BitcoinJ is not supporting that). So it seems this would be a hack causing more problems as it might fix and we should find out why broadcasting of the originator does not work, as it might not work again on the peer as well.

##### Regarding 2:
It seems it is mainly related to the currently low trade limits for fiat. It should be less of a problem after 1.2. If it continues we should consider to increase buyers security deposits and min. sec. deposit. 

One other option might be to add a reason for dispute enum ("Possible future trade") which triggers a popup at both traders at dispute close. At the buyer the popup would communicate that there is some reason to assume that he was doing a "future trade" and the seller might block him for further trading. The more he gets blocked the lower are his market possbilities. This might motivate him to not repeat future trades.
The seller will get a message that the buyer might have been enganged in a future trade and he get asked if he wants to block that user to not trade again with him. 

It seems that at most such future trades cases the buyer is not responding at all. The mediator should send a message with the above warning before he closes the case to give him a change to change his strategy. If the buyer was not responding and the price change since take offer fits into the patter of a future trade it is likely the cause. But we have to make sure to communicate that there is no clear evidence for it and give the buyer the benefit of a doubt (might be network issues or other reasons).

##### Regarding 3:
We probably cannot do much here. If there are still Revolut issues we should try to fix that in the UI side with better explaination or limiting the account ID (email or phone). Not sure if there are issues with Transferwise as well. This was always problematic in the past and should be addressed how to deal with it.

##### Regarding 4: 
The messages not arrived issue is likely related to seed node stability. The monitoring need to become a working alarm system where we can reliable detect any issues. It seems much more stable as it was in the past, but we are still not at our goal. 
Beside that we could add UI improvements to make it more clear that after sending a message the user must not shut down the app too quickly (or better add a delay at shutdown code if a message was sent recently).
The issue that the "payment started" message does not arrive might be a bug in the trade process code.

##### Regarding 5: 
The UI issue can be resolved by adding a red notifiaction icon to the tabs (not trivial to do that in JavaFX tabs unfortunately) so the user sees in which tab he received a message. 

If there are other open UI issues we need to find out by requesting more user feedback. Support channels and mediators should proactively collect such information and provide it to devs.

##### Regarding 6: 
Real scam attempts seem to be not an issue. We might consider to add an alternative for Pagesigner. It seems there is another tool out yet, but don't know how it works and how safe/privacy protecting it is. But Pagesigner is not needed often anyway, so I think thats a low prio.

### Feedback from keo
#### Reasons for disputes:
1. (50%) Bugs with tx not published. 
2. (30%) Missed messages: Both dispute messages and payment started message.
3. (20%) Buyer not starting payment if BTC price changes too much ("future trade"). Seems to happen a lot at Brazil market.
4. Some issues that mediation close message did not arrive at traders.

##### Regarding 4: 
We should show a popup to the mediator in case he receives a message at a closed case so that he gets alerted that the close might not have worked and he can re-open and close again.

## Recommended action plan
1. One or two devs who are experienced with the trade protocol and wallet should work on fixing the open bugs. We should try to find a way how to reproduce the issues (was not possible so far). 
2. We should find a dedicated support lead who gets a professional support system installed and manages the support area
3. We should create manula/FAQ for support agents (after the critical bugs are fixed, as dealing with those is a major education effort).

-- 
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/130
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191027/84431d8a/attachment-0001.html>