[bisq-network/proposals] Off-chain trade protocol based on symetric security deposits in BTC (#76)

Thu Apr 4 00:57:43 UTC 2019

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

## Off-chain trade protocol based on symetric security deposits in BTC

### Overview

Similar to the idea of the [off-chain trade protocol based on BSQ bonds](https://github.com/bisq-network/proposals/issues/32) I propose an alternative idea to use the 2of3 MultiSig with a different payment allocation as security deposit for an off-chain transfer of Bitcoin-independent assets.

The benefit is that the transfer of the assets is completely independent of Bitcoin or any blockchain. The downside is the requirement to secure the trade with a higher amount as the trade amount.

### Description

Assume 2 traders want to exchange Monero with USD. 
They both lock up a BTC amount into a MultiSig address. This amount is higher than the trade amount. As soon the deposit tx is confirmed both have to make their transfer to the other party and confirm when they have received the funds from the peer. Once both have confirmed receipt they will sign the payout tx.

The locked up amount contains a bit more than the BTC equivalent of the exchanged assets to create an additional incentive so that the traders follow the trade protocol (same function as security deposit in current trade protocol). 

There are 2 variants possible. One is similar to the current trade protocol where a trade fee tx is used to prepare the exact input amount. Another option is to avoid those extra transactions and add change outputs to the deposit tx. It needs further investigation to see which model is better here, both have their pro and cons. In the following model we assume that the correct input amounts have been already be prepared (e.g. via the trade fee tx). 

### Example
Lets assume 1 BTC = 5000 USD and 1 XMR = 50 USD, so 5000 USD = 100 XMR. 
Alice and Bob make a trade of 5000 USD to 100 XMR. Lets say the extra security deposit is 10% of the trade amount (0.1 BTC) for both. For the miner fee we use 0.0001 BTC.
Alice wants to sell 100 XMR and Bob want so buy it. 

Alice makes an offer and publishes it to the network. She reserves 1.1 BTC in her wallet for a potential taker.
Bob takes her offer and both create the deposit tx with following structure:

Deposit tx:
Input 1 Alice: 1.1001 BTC
Input 1 Bob: 1.1001 BTC
Output 1: 2.2001 BTC in 2of3 MultiSig (arbitrator as 3rd key holder)
Miner fee: 0.0001 BTC

Order of inputs can be randomized.

After the deposit tx is confirmed both need to start their payment. The XMR sender need to use a Monero wallet which is capable to provide a tx payment proof. 
Alice sends 100 XMR to Bob and provides the payment proof to Bob. As soon Bob has received it he confirms receipt and sends Alice his half signed payout tx.  
Bob sends 5000 USD to Alice bank account. As soon Alice has received the funds she takes Bobs half signed payout tx and adds her signature and publishes the payout tx which looks like following:

Payout tx:
Input from deposit tx: 2.2001 BTC
Output 1 Alice: 1.1 BTC
Output 2 Bob: 1.1 BTC
Miner fee: 0.0001 BTC

The output order can be randomized.

So that was the happy path... The protocol works the same way if Alice is the XMR buyer or the taker.

Lets look into a case where one party is malicious.

Both start the trade as descibed above. Lets assume Bob is malicious.
After Alice has sent the XMR to Bob he does not start the payment of the USD to Alice and also does not confirm the receipt. 
After the trade period is over Alice opens a dispute. She can proof to the arbitrator with her payment proof that she sent the XMR. If Bob cannot provide a proof that he has sent the USD to her the arbitrator will make the full payout to Alice side so she gets reimbursed for her lost XMR with Bobs locked BTC as well gets his security deposit as reimbursement for the lost time and trade opportunity. In fact she has traded XMR for BTC in that case.

On the Fiat side the proof is not as strong as it is on crypto currency side but that problematic is the same with the current trade protocol and in reality all disputes can be resolved. For instance if Bob claims he has sent the USD but he does not want or cannot provide a [PageSigned document](https://tlsnotary.org/pagesigner.html) to proof his side but Alice provides a Pagesigned document of her banking webpage which shows that she has not received the funds, the arbitrator will close in Alice's favor. As said there is no perfect solution for the Fiat side but in 3 years history of Bisq all disputes have been resolved. Scammers don't have a good position here...

If Alice is malicious and never sends the XMR it is much easier to resolve as it is her responsibility to provide such a tx proof. If she does not or cannot she will lose the case.

If the trading pair is not including Fiat it is also much easier as any altcoin transfer can be looked up at a block explorer.

One problem might arise that there is an incentive to wait until one has received the funds from the peer before sending his own funds. In the current trade protocol it is clear that the BTC buyer needs to do that transfer as the BTC transfer is done in the payout. To mitigate that problem both need to indicate when they have started to send the funds and if they lie about that (clicking too early) and it can be proofen in a dispute that in reality the transfer was delayed a penalty can be applied in a dispute. The XMR or altcoin transfer can be checked with the block time. On the fiat side the payment statement usually contains also a time stamp. Maybe an additional arbitration fee could be used to avoid that traders speculate on late payments. If trade period exceeds the late payer risks a penalty.

#### Possible side effect
As the input and output amounts are symmetric for both traders we might gain CoinJoin like properties. If that is really the case or if some aspects (fee, change,...) will leak the information which input leads to which output requires more investigation. Tx graphs and coin merge might make a CoinJoin like obfuscation ineffective. It will also depend if there are already prepared inputs or if we avoid the fee tx and use change outputs. I think to really get solid CoinJoin it will require much more work on the wallet management to avoid coin merges which would leak information. Beside the compelexity of such management it will come with usability constraints as a user cannot spend certain combinations of utxos without leaking information which would render the CJ ineffective. And worse if your peer leaks that it will affect you as well and you even don't know about that.... 

#### Relation to new trade protocol
This concept should not be in conflict with the [proposal for the new trade protocol](https://github.com/bisq-network/proposals/issues/52). But it would be wise to take requirements of both into account once more concrete work starts on that.

-- 
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/76
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20190403/c8eb9f9f/attachment.html>