Off-chain trade protocol based on symmetric security deposits in BTC

[ManfredKarrer]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Off-chain trade protocol based on symmetric security deposits in BTC

Overview

Similar to the idea of the off-chain trade protocol based on BSQ bonds I propose an alternative idea to use the 2of3 MultiSig with an equally sized 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 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.

CoinJoin like properties?

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 CoinJoin 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. But it would be wise to take requirements of both into account once more concrete work starts on that.

[meapistol]

This can also be implemented in LN where 2of3 multisig can be used: (https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-January/000403.html)
I say this since Bisq should be future-proof and on-chain fees will go up drastically.
And it moves Bisq towards being a decentralised arbitration system, a lá lex mercatoria, which I think is positive. Given specialised arbitrators (who can judge delivery and quality) the traders can trade whatever they want, maybe oil.

In general BSQ should be used only by those who want to, since it introduces friction, and this proposal is a step in this direction.

I suggest that the traders can chose which dispute resolution mechanism they want and then one can let usage decide what to put effort on. There is a cost associated with having to lock-up a large amount of BTC in escrow. Maybe the deposit should be less than the trade volume and be a parameter that can be changed by stakeholders, or set by the traders.

[ManfredKarrer]

If the amount is less the one who received the funds could not send his part and makes a gain even if he loses all his locled BTC.
E.g. If Alice has sent 100 XMR and Bob does never pay the USD and there is only 0.5 BTC in deposit on both sides Bob loses only 0.5 BTC and has gained 100 XMR thus has stolen 2500 USD from Alice.

[ManfredKarrer]

@meapistol I talked to a LN dev at the Breaking Bitcoin conference in Lisbon last year and he told me that - yes there are some theoretical ideas how to do it but nobody is working on it and it is unlikely that it will be implemented. We will see, but I fear we cannot count on something which is not clearly on the roadmap and at least under development.... But agree that long term the tx fee will become a problem. The BSQ based approach would avoid that as the bonds there are long living and therefor don't require a on-chain tx for each trade.

[mrosseel]

comment probably destined for @meapistol :)

[ManfredKarrer]

@mrosseel Yes, fixed it ;-)

[huey735]

@ManfredKarrer would these locked bitcoins be BSQ bitcoins or simple bitcoins?
@meapistol My initial reaction was similar to yours but I think it's worth putting to the test to see how big is the friction really. It may be that the market is quite comfortable with acquiring BSQ and use it as collateral for trades.

I see this working well for people who regularly buy XMR (or whatever). They could use the same collateral and in a year, with 12 trades buy up to 12 times the value of that collateral. I worry however about the people's perception of their privacy. Depending on how the system is implemented the other party can know how much BTC and XMR I own and my fiat account details.

Also, any solution to reduce the on-chain fees are welcome. Do you have any material on multisig on Lightning Network besides that link @meapistol ?

[ManfredKarrer]

This proposal is based on BTC, so no BSQ involved.

[ghost]

@ManfredKarrer wrote

arbitrator as 3rd key holder

I guess this is how things works already today in Bisq (?)
If yes, could it be imaginable that the 3rd key is not provided a priori to the arbitrator,
but instead, sliced in several parts, and all the slices being disseminated in the Bisq network ?
see https://en.wikipedia.org/wiki/Secret_sharing
And it's only in case of dispute that the slices are reconciled and provided to the arbitrator.

[ManfredKarrer]

Someone need to craete the private key which will be then split with sharing. So that person will have the key anyway and you don't gain on the security side.

[meapistol]

A high BTC-security deposit, higher than the trade amount, can also be extended with a very long time to opening of a dispute, a messaging system between the traders and the ability of the buyer to do a payout to the seller (in case he cannot pay). Then arbitration will not be needed and the incentives to blackmail will be very low.

[MwithM]

Closed as stalled