Arbitrator (legacy 2-of-3 model)

[cbeams]

This role is responsible for arbitrating Bisq exchange trade disputes.

See:

• The Arbitration section of the original Bisq whitepaper
• The dedicated Arbitration System doc

[cbeams]

2017.12 report

I serviced approximately 55 trade disputes during the month of December, which is many more than usual (I don't have exact stats for comparison as this is the first month I'm reporting these numbers).

A number of these trades were challenging and drawn out due to blockchain congestion causing slow trade confirmations. Indeed, it's these delayed confirmations that required most trades to be opened in the first place.

Something that came up multiple times in the process was what to do about "no-fault" disputes, e.g. when an external force causes a trading window to be exceeded. I had several lengthy discussions about this with traders, and would like to put together some kind of discussion that will move toward a policy on this matter. Trade WQYVFAKS in particular is important here. It was the most detailed conversation I had with traders on this matter, and both traders agreed to let me use the transcript of our chats to help in discussing and crafting this policy. I am going to have to come back to this later, but wanted to document it here briefly for future reference.

Another major issue this month was timeouts on maker/taker transactions causing lost fees. @ManfredKarrer believe's he's got this problem nailed down (It's bitcoinj not being able to handle transactions with dependent v2 transactions), but it remains to be seen whether this will actually solve the problem. In the meantime, I'm still working through a considerable backlog of these issues to get everyone affected reimbursed or otherwise appropriately taken care of. This has been a huge drain on my time.

A final issue that came up this month was dropping of arbitration chat messages. This has only happened a few times, and we believe it was due to unstable seed nodes or something in the new netlayer Tor library we're using. @keo-bisq and I have been dealing with this in a variety of ways, and we believe that everyone is getting taken care of, but even the possibility that we cannot see a trader's message, or that they cannot see ours adds a level of uncertainty to the arbitration process that ends up eating a lot of time and energy. @ManfredKarrer has rolled back the netlayer changes in our seed nodes (where mailbox messages get queued on the network), and we'll see how that works. Again, I only experienced this issue several times, and I have not experienced it since the rollback, so we may be out of the woods on this one, but we still have to be on high alert.

Overall, these issues notwithstanding, arbitration still went quite well this month. In the end, we were able to keep up with the huge surge in trading volumes, but it certainly stress-tested the system (and us as arbitrators) in the process.

[cbeams]

2018.01 report

I arbitrated approximately 50 trade disputes this month, which like last month is higher than usual, but this was due at least in part to the timeout and transaction broadcast failure issues that came up in v0.6.3 and v0.6.4, which I've written about elsewhere in this month's reports.

One significant change we've instituted over the last month is creating "tracking issues" for arbitration-related problems, e.g. bisq-network/bisq#1173, where we're tracking cases of dropped arbitration messages (or what we think are such cases, anyway). These issues provide @bisq-network/arbitrators with a more systematic approach of reporting problems to @bisq-network/exchange-maintainers and prioritizing what should get fixed first based on severity / frequency of incidence, etc.

Also, I want to start keeping a stat here in these monthly reports about our trade-to-dispute ratio. I arbitrated 50 trades, and that means that @keo-bisq probably did roughly the same. That's 100 trade disputes out of a total of 620 trades for the month. 100 / 620 = 16% of trades going to arbitration. That number is quite a bit higher than my intuition said it would be. I've been thinking that somewhere between 5–10% of trades go to arbitration. Again, the last couple months' numbers are probably inflated here because of the unusual bugs we dealt with. Let's see how it goes in the months to come.

One thing that may really help reduce the number of arbitration cases are the changes coming in v0.6.5 that will start the trading period clock only after a trade's deposit transaction has confirmed. In blockchain congestion scenarios, this will certainly reduce the number of tickets coming in.

/cc bisq-network/compensation#35

[cbeams]

2018.02 report

I arbitrated ~30 trade disputes this month, and the second half of the month was very quiet. Many days went by without a single ticket coming in, which is unusual.

I'm still seeing occasional dropped arbitration messages, and I've logged them at bisq-network/bisq#1173.

A number of trades continued to suffer from dropped trade protocol messages, and I've logged them. It seems to be the "Payment Started" message not getting through most of the time. I've logged these as well at bisq-network/bisq#1174.

Additionally, several times this month people dealt with an error in which Bisq claims the user has funds locked up in a failed trade. The popup that explains this pops up over and over again. I experienced this myself when doing a test trade with @flix1. It seemed to be caused by me clicking "Payment Started" on our trade when his client was not online. My client was never able to send the message, and then at some point, possibly after restarting Bisq, my client started to raise this popup repeatedly as well. I worked with @keo-bisq to get the trade dispute closed out and the problem went away. This problem needs to be properly documented, though, and it hasn't been yet.

/cc bisq-network/compensation#40

[cbeams]

2018.03 report

I arbitrated 40 cases this month.

Major issues continue to be:

• dropped "Payment Started" trade protocol messages (Track dropped trade protocol messages support#84)
• failed bitcoin transaction broadcasts (Track trades with failed Bitcoin transaction broadcasts support#94)
• dropped arbitration chat messages (Track dropped arbitration messages support#85)

By far the most important issue to fix is dropped 'Payment Started' trade protocol messages.

/cc bisq-network/compensation#57

[cbeams]

2018.04 report

I arbitrated 45 cases this month.

Major issues continue to be:

• dropped "Payment Started" trade protocol messages (Track dropped trade protocol messages support#84)
• dropped arbitration chat messages (Track dropped arbitration messages support#85)

A seemingly disproportionate number of issues came up around the new N26/MoneyBeam payment method as well. Buyer's having issues adding seller's to their contact book or some such, and before they did it, they couldn't send the seller more than 100 EUR. I don't yet have a support tracking issue for this, but need to get one set up. Heads up, @bisq-network/payment-method-experts.

By far the most important issue to fix remains the dropped 'Payment Started' trade protocol messages.

/cc bisq-network/compensation#68

[cbeams]

The following is our dispute-to-trade ratios over the last 5 months:

2017.12: (55*2)/711 = 15.5%
2018.01: (50*2)/620 = 16.1%
2018.02: (30*2)/576 = 10.4%
2018.03: (40*2)/792 = 10.1%
2018.04: (45*2)/976 = 9.2%

The numerator is the estimated number of disputes arbitrated, taking my own values as tracked in the monthly reports above, and multiplying it by 2 to take into account the likely number of trades that @keo-bisq arbitrated as well.

The denominator is the total number of trades processed on the network in that month.

The resulting percentage is our "dispute rate".

I would estimate that we can get this value down to 6% just by fixing the known issue around dropped "Payment Sent" protocol messages (bisq-network/support#1174).

[cbeams]

2018.05 report

I arbitrated 46 cases this month.

Major issues continue to be:

• dropped "Payment Started" trade protocol messages (Track dropped trade protocol messages support#84)
• dropped arbitration chat messages (Track dropped arbitration messages support#85)

Another issue I haven't brought up before is the problem of traders sending arbitration messages after I've closed their ticket. When this happens, I never see the additional messages, because the ticket is hidden away from me, and because no sort of notification occurs when closed tickets get new messages.

Trade NX5C4W5F was such a case, and it left the buyer very worried for nearly a month. The buyer's bitcoin had never been released to them, even though I closed the arbitration ticket in their favor. The payout transaction never occurred, and I believe this is because my close ticket message / payout transaction signing message never made it to the buyer's client in the first place. I believe it's for this reason as well that the buyer was able to continue messaging me: their client never got the signal from mine that the conversation was over. Note that also have reason to believe, from the content of his comments, that he never received any of my arbitration messages.

So this specific problem can probably be generalized to the known problem of dropped arbitration messages. We may be able to mitigate the effects effects of this specific problem, though, without necessarily having to fix the general problem. Getting any kind of notification that a closed message is still active would be helpful, but that's probably a lot of code we wouldn't otherwise want.

@ManfredKarrer has been thinking about doing "read receipt"-style messages as a way of solving the dropped message problem, i.e. getting an explicit confirmation message from your peer that they definitely got your message, with, say, a hash of its contents to prove it. We could build on this approach to ensure that my arbitration ticket doesn't actually close until we've gotten confirmation from the peer's side that their side is closed as well.

In any case, this problem creates a nasty experience for users, so would be good to remedy / mitigate in some fashion asap.

(I'll create a dedicated issue for the above new issue shortly)

/cc bisq-network/compensation#74

[cbeams]

2018.06 report

I performed arbitration for 52 disputes this month (second highest number since I started counting in December, and it was the big run-up in December that had 55 disputes). Many were failed trades due to timeouts / non-broadcast txns, some were due dropped trade protocol messages, many were due to run-of-the mill mistakes and protocol violations. I certainly ran into several dropped arbitration messages along the way; very much looking forward to the ACK messages in v0.7.1 helping us to track this stuff down.

/cc bisq-network/compensation#89

[cbeams]

2018.07 report

I performed arbitration for 27 disputes this month. This is a steep drop off from recent months, which may be attributable to lower-than-usual overall Bisq trading volume in July, the new ACK messages that came out in v0.7.1 to help avoid dropped trade protocol messages, or a combination of both. Let's see how the trend continues to play out over the months to come.

/cc bisq-network/compensation#101

[cbeams]

2018.08 report

I delegated my arbitration duties to @ManfredKarrer this month, and so have nothing to personally report. I may take this duty back over shortly.

/cc bisq-network/compensation#114

[cbeams]

2018.09 report

I resumed my arbitration duties this month, and performed arbitration for 23 disputes. This number is lower than it would have been, as Manfred was still registered for a number of cases that started the month prior but only went to arbitration after the 1st of the month.

Noteworthy issues:

• I had 3 or 4 cases where dropped arbitration messages caused significant problems, slowing down and confusing the resolution process.
• I had two failed trades where transactions failed to broadcast. Such issues have been rare lately, so it was surprising to see these two: Fee reimbursement for trade 02645125 support#139, Fee reimbursement for trade 51289674 support#140.
• I created the following issue to deal with a known UX problem where buyers select the wrong bank account at payment time, causing particularly time-consuming arbitration disputes: Make more prominent which payment account should be used to complete a given trade bisq#1733

/cc bisq-network/compensation#139

[cbeams]

2018.10 report

I arbitrated 68 disputes this month, and as @ManfredKarrer reported at bisq-network/proposals#52 (comment), quite a few are due to bugs / networking issues. The most common ones this month are dropped trade protocol messages between buyer and seller, where the seller doesn't know the buyer has initiated payment because the 'Payment Started' message never gets to the seller, or the seller's 'Payment Received' message never makes it to the buyer's client. These issues are happening even though the affected clients report that the message was 'received by peer'. In any case, these all end up in arbitration, and as Manfred reported, they are responsible for something like 40% of all cases.

On the bright side, it's good to see that the number of disputes has not gone up linearly with the number of trades during this recent volume spike. 68 is certainly more than I usually do in a month, but only by 10 or 20, i.e. a 25% or so increase. That's pretty good considering that we doubled the number of trades we usually do this month (2000 vs 1000). Much of this can be attributed to the fact that most of this month's volume increase was Monero-related, and that Monero users are generally more sophisticated and less likely to end up with disputes, but it doesn't explain why we wouldn't see 2x as many bug-related disputes.

In any case, getting somebody to work on these dropped message bugs is important.

/cc bisq-network/compensation#160

[cbeams]

2018.11 report

I arbitrated 91 disputes this month. Common causes were similar to those reported last month, including:

• Buyer's 'Payment Started' message not being received by seller
• Bitcoin transaction broadcast failures

Manfred believes he may have solved one of the causes of messages being dropped. We'll see how that fix plays out with the release of 0.9.0.

/cc bisq-network/compensation#179

[cbeams]

Per #1 (comment), I've handed off my arbitration duties to another contributor that will remain anonymous for now. I generally plan to pick this duty back up when I return.

[cbeams]

Closing as superseded by Refund Agent at #93 (which will actually be renamed to Arbitrator shortly). In any case, @keo-bisq and @Arbitrator22 have revoked their legacy arbitration keys and are no longer performing this role.