[bisq-network/proposals] Proposal for new trade protocol without the need for arbitrators (#52)

Thu Oct 25 06:37:12 UTC 2018

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

## Overview
We suggest a change of the current Bisq trade protocol which is based on a 2-of-3 MultiSig deposit transaction where an arbitrator is the 3rd key holder who helps in case of disputes and can make the payout transaction with one of the traders. The new protocol would be based on a 2-of-2 MultiSig deposit tx where only the 2 traders are the key holders. We would delegate the dispute resolution (which in fact is 99.9% customer care work and no real disputes) to the users as first step and if they cannot resolve the issue themselfes to mediators. In case the peers do not cooperate to sign the payout transaction as defined in the trade contract there is an option for the victim of getting reimbursed for the lost BTC amount by the BSQ stakeholders. If the request gets accepted in DAO voting by the stakeholders he get issued the amount of BSQ which is equivalent to the lost BTC. To avoid abuse we introduce a time locked transaction which will send the fund from the 2-of-2 MultiSig deposit tx to the receiver of the Bisq donations (see #48). Before being able to request for reimbursement that timelocked payout tx to the donation receiver need to be confirmed. 

This model actually is an insurance model where in case of damage for one trader he can get compensated by the BSQ stakeholders. For the BSQ stakeholders it still is much cheaper than spending lots of funds on arbitrators. It is assumed and need to be achieved that reimbursement requests are rather rare (not more then a few a month - or even less). The system is flexible and there is no automatation which leads to reimbursements, so it can be adjusted over time to optimize the results.  

## Problem with current arbitration system
The current arbitration system comes with several problems:

- It is not open and decentratlized yet bcause of unsolved security risks. Plans to secure the roles by BSQ bonds will make it better but is still not a fully satisfying solution as well. Bonds will be very high and therefore limit the potential candidates. The higher the trade volume on Bisq the higher are the required bonds as well, which creates a scaling issue.
- Bisq cannot scale if we cannot distribute that role to non-english speaking arbitrators.
- It carries legal risks (some jurisdictions might interpret holding a key in a Multisig tx as shared control over the funds and therefor interpret the arbitrator as financial intermediary).
- It is expensive: Arbitration work requires lots of knowledge about Bisq and is a high-trusted role. Locking up high bonds need to be compensated by some sort of "interest" payment.
- It is very inflexible: An arbitrator cannot revoke short term if he wants to make holiday or is sick. Private keys (BTC and Tor) cannot be handed over to a deputy.

## Solution: Get rid of the arbitrators
Bisq actually started with the idea of a 2-of-2 Multisig deposit tx and only after concerns regarding potential blackmail risks in such a scenario we dropped that idea and introduced the arbitration system with the 2-of-3 Multisig.

### 2-of-2 Multisig transaction
The trade protocol is similar like now just that there is no 3rd key in the Multisig deposit tx. the 2 traders are the only keyholders. In case the trade gets successfully completed both traders sign the payout transaction as defined in the trade contract.

### Timelocked payout transaction to donation receiver
After the traders have created the 2of2 Multisig deposit tx they will additionally create a payout transaction which is timelocked for about 1 month and where the receiver is the donation address defined by the Bisq DAO (see #48). In case both traders do not cooperate to make a normal payout any of the 2 traders can (but don't need to) publish that transaction and therefor spending the funds from the deposit transaction to the donation receiver address. If both agree they can still wait longer and can still create a normal payout at any time. But any of the 2 traders have the power to terminate the trade by publishing the alternative tx. This will be the requirement for requesting a reimbursement.

The technical details which form of timelock (nLocktime, CLTV) we will use is up for discussion and need more investigation.

There is a non-atomic process of the co-signing of the timelocked payout tx (TLP). The seller has more to lose (as he has the trade amount added in the deposit tx) so we will let him be in the role of the deposit tx publisher. He will hold back the fully signed deposit tx before he has received the fully signed TLP tx. 

Here is a rough sketch of the protocol:
1. The seller sends his tx input data to the buyer. 
2. The buyer creates with the sellers input data and his inputs the deposit tx and signs his inputs and send it back to the seller.
3. The seller signs his inputs. He now creates the TLP tx and sign his part of the multisig and send that to the buyer.
4. The buyer signs his part of the TLP and send it back to the seller. The buyer at that point has the full TLP tx but he could not broadcast it because the deposit tx is not broadcasted and therefore it would be invalid.
5. The seller has now the fully signed TLP tx and broadcasts the deposit tx. 

The seller has the security that his trade amount is only locked in the deposit tx if he has the fully signed TLP tx which would enable him to request for reimbursement in case the buyer do not cooperate.

The buyer will only send the fiat/altcoin payment if the seller has followed the protocol and sent him the TLP tx. If the seller would have broadcast the deposit tx without a TLP tx the buyer would not start the payment. The seller cannot request the reimbursement as there is no TLP signed by both. In such a case the buyer would also lose his deposit but the seller has much more to lose, so it would be an economically irrational strategy. 

### Conflict resolution
>From our experience as arbitrators we have seen that the huge majority of cases are no disputes but cases with bugs, banking problems or usability issues/user mistakes. Real disputes have been maybe 1 or 2 - I even can't remember any. Sometimes a user does not respond and with the currently short tolerance of 2 days response time such cases get closed then in favor to the other trader. Other cases are "future trades" - in times of high price volatility the trader who would have a disadvantage by completing the trade with the "old" price "cancels" the trade by not completing it. Only the BTC buyer can do that. This is the reason why we have a higher security deposit for the buyer (which he loses in such cases).
We need to increase that security deposit to make such cases very rare.

We want to delegate most of the conflict resolution process to the traders and if needed to mediators. There will be a direct in-app messaging system (like the current one in the arbitration system) which provides encrypted and signed communication. This is important to be able to proof abuse (trolls, scam attampts in chat,...). This communication will be on a per-trade base, so with each trade you can see the history of the messages.

The mediator is basically a customer care agent who can help if needed. The details of that need more discussion but it should be implemented with scalability and flexibility in mind. It should be easy to become a mediator. The current support section in the Bisq Forum is close to such a goal. It is open if that need to be a bonded role but likely it will be. Mediator migh play a role for applying negative reputation score (#27) in case of misbehaviour. 

The whole traders communication and mediator area needs more discussion and refinement.

### Traders defined alternative payouts
The traders can agree to change the normal payout as defined in the contract in case something went wrong or if a peer violated the trade protocol. We got several cases of such "light" violations: Paying too late, using a different bank account as defined in Bisq or using BTC in the reference field, etc. Such "light" cases could be resolved by the traders agreeing to an alternative payout (e.g. a part of the security deposit goes to the other peer). Another scenario is that the fiat transfer failed (e.g. banking problems) and the seller need to get the refund.

The process would be that the peers agree on a payout and then send their signed payout tx to the other peer who will then broadcast the tx.

### Reimbursement
In case a trade does not get completed because the peer is either not willing to complete, not responding or a scammer, the victim can make a request for reimbursement of his lost BTC.
He need to broadcast first the timelocked payout transaction where the funds goes to the donation address (can only be done after the lock time has passed). In the voting phase the stakeholders will vote on that request and if it gets sufficient support he will get the BSQ issued which are the equivalent amount to his lost BTC. To avoid abuse we might set the reimburesement rate a bit lower (e.g. only 90% get reimbursed). 

## Risks for abuse
With the requirement that the funds in the deposit tx are spent to the donation address we avoid that a scammer could run 2 Bisq nodes, trade with himself, simulate that he got scammed and request a reimbursement. After he received the BSQ he could make the payout to himself and thus have gained the BSQ without haveing lost any BTC. As we require that the funds are spent to the donation address this attack is not possible. Furthermore we add a small loss by only reimbursing 90%. Beside that it requires time and effort to get the reimbursement which should limit it to those rare cases where the traders cannot come to a cooperation. 

It is assumed that the donation receiver address is a NGO-like organisation (e.g. Tor,...) or personality with a very high reputation (like Andreas Antonopoulos,...) and that those donation receivers will change from time to time via voting. Thus the theoretical risk that the donation receiver is the scammer (or colluding) and doing reimbursement requests as described above is very low. Beside that, the BSQ staekholders do not need to accept requests and if they are too frequent or there is some suspicious for abuse they can decline it. They can also change the donation receiver if there is any reason for doubt.

### Non goal
It is not intende to be used for those cases where makers or taker lose the trade fee because of technical problems. We will continue to reimburse those in a non-beaurocratic way and those amounts are too low to justify the friction and costs it would create to use the reimburesemnet request model.

## Deployment
This change will be a kind of hard fork on the trade protocol level. We could support both protocols in parallel but probably it is better to make a hard change. Old client will still be able to trade between other old clients but all those who will update are moving to the new protocol. We should also have a defined timeout for not supporting the old protocol anymore and to make it possible to revoke all arbitrators. We should try to implement a conversion of existing offers to the new protocol so the makers are not losing already paid maker fees. 

Details about the deployment need further discussion.

## Relation to other proposals
There are several other open proposals and we need to consider if we should combine those if do a bigger change and a "hard fork":

- Would it make sense to go directly to the off-chain trade protocol idea instead of sticking with a multisig based protocol (#32 )? If so, would this replacement for the arbitration work there as well? 
- Can we find a way to get rid of the trade fee transactions so that we have only 2 instead of 4 trade transaction (no proposal and no concrete idea how to do that but should be investigated if there is a way)?
- Can we add support for offline offers (#44)?
- Integrating a reputation system (#27)

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