Off chain trade protocol using BSQ bonds

[ManfredKarrer]

This is not really a proposal intended to be implemented short term but with the DAO/BSQ we will have new interesting options I would like to share.

Overview

The current on-chain trade protocol with the 2-of-3 MutiSig deposit tx has several disadvantages:

1. It is dependent on low tx fees
2. The 2-of-3 MutiSig deposit tx makes the arbitration system pretty inflexible and carries some risks which are difficult to mitigate.
3. It comes with privacy weaknesses as the trade leaves a trace on the Bitcoin blockchain.

With the DAO/BSQ we have a new feature at disposal which we can use to solve all of the above problems: BSQ bonding

BSQ bonding

BSQ bonding was introduced mainly for adding security for roles which cannot meaningfully be decentralized like holding the domain name or owning the Github account. Those role owners need to lock up a certain amount of BSQ as security that they do not abuse their powerful position.

The lockup mechanism in BSQ is rather simple. We add a special OpReturn data which marks a BSQ tx as lockup tx as well as the unlockTime (used when unlocking the bond). A locked up BSQ bond cannot be spent as no other peer would accept an output from a locked up tx. The only way to spend it is to make a unlock tx (again a special opReturn data marking that tx as unlock tx) to athe users own address. With that unlock tx the unlocking time starts (was defined in blocks in the lockup tx.) After the defined number of blocks has been passed the user can spend that tx output like any other BSQ output - it is now fully unlocked.

So there are 3 states:

1. Locked up - not spendable
2. Unlocking (unlock Tx published but unlock time not passed yet) - not spendable
3. Unlocked (unlock time passed) - spendable

In case for bonded roles the role owner need to lock up the required amount and keep that locked until he revokes the role. Then he need to wait for the unlockTime until he can spend that BSQ normally.

If during that time (lockup time or unlocking time) anyone makes a confiscation request for the role owners bond because of some clear evidence of abuse by the role owner (e.g. I as Bisq domain name owner promote on the Bisq webpage BSQ-Cash as the real and only BSQ ;-)) then his locked up bonds can be confiscated. That will require a very high quorum (e.g. min. 100 000 BSQ are needed as stake in voting) and threshold (e.g. > 85% must accept the proposal). That should limit such confiscations to very clear cases where the BSQ stakeholders are very sure that the role-owner has violated his role duties. The confiscation is just marking the BSQ output invalid and no other user would accept such BSQ, so they got un-colored (burnt) and have lost their value.
Confiscation could be done also partially - so that only part of the bond gets burnt (not impl. yet but probably planned to do it to be more flexible).

This model of bonding could be used for other use cases as well:

1. Buying reputation by locking up a bond
2. Securing a trade by requiring a BSQ bond for both traders
3. Locking up BSQ as security mechanism: If the BSQ gets stolen the owner has a chance to request a confiscation and afterwards request new issuance of his lost BSQ (of course only in 100% clear evidence). That way the thief sits on invalid BSQ. That model has advantage over MutiSig as you don't need to find others to trust with your keys but the trust model is different: You have to trust the super majority of BSQ stakeholders that they are acting honest.

BSQ bonding as add-on to current trade protocol

A offer maker can make a BSQ bond and add the hash of his signature pub key to the OpReturn data of that lockupTx. With that he can later proof with a signature that he is the owner of that bond. E.g. he receives some challenge data, creates a signature from it using his private key and provide his public key as well as the txId of the lockup Tx. The peer can then verify that the hash of the pubKey matches the hash in the lockupTx's opReturn data, the lockupTx is unspent and that the signature is valid by verifying it with the pubKey.

The maker could add the signature of the maker fee txId (no one can re-use that signature as there will be a different txId) to the offer as well as the pubKey and the lockup txId. Any taker can verify the amount of locked up bonds and that the maker is the owner of the bond. The maker could require that the taker also use a reputation bond for securing the trade and would verify that the takers bond is correct when he takes the offer.

This model would only require to put a bit of extra data into the offer and do the required verification in case the bond is used. Implementation effort should be rather low.

Securing risky payment methods

One use case could be to use a bonded reputation to guarantee that the trader is not making a charge back in case unsafe payment methods like Venmo or CashApp are used. The unlock time need to be rather long for such cases as charge back might be still possible after a few months.

It also can be used for securing Face to Face trades against risk of robbery - though here it might be more difficult to deliver temper proof evidence, but the fact that such a trade might require a BSQ bond might be enough to keep criminals out as they run a higher risk to lose more money as they could gain and they don't know in advance if the peer can provide good evidence after a theft (e.g. using public cameras footage, police report,...).

But we could go further and remove the security mechanisms we use atm completely (deposit, 2-of-3 MultiSig) and use the security of the bonds as sole protection. This would make the trade completely independent of any crypto currency as smart contract carrier (beside that BSQ is technically Bitcoin ;-)).

Off-chain trade protocol

The maker can define a contract from some templates (e.g. use public Bisq arbitrators or use private arbitrator or whatever he defines). The taker will view the trade contract before taking the offer so when taking it he agrees to the makers contract. The trade itself can be then completely off-chain: It does not require a crypto currency at all, e.g. it could be a USD-EUR exchange.

In case of a dispute the arbitrator (or whatever is defined in the contract for dispute resolution) would investigate and make his judgement. This judgement can be taken as base for a confiscation request to freeze the locked up bonds of the misbehaving peer. The modality of the contact and dispute resolution can be defined arbitrarily and the publicly exposed facts about the trade required for the stakeholders to make a decision can be limited to a binary recommendation of the arbitrator. With that the privacy is protected to a high degree and only the arbitrator will learn about the details of the trade. But it is just one possible contract/dispute scenario, it is basically totally open to whatever the peers define among themselves.

If Bitcoin is part of the trade it can be sent via Lightning network without requiring to implement a smart contract on Lightning (which would be a big challenge).

Makes arbitration less critical

This model will remove the requirement for designing a fully decentralized and safe arbitration system (the arbitrator as key holder in the trade has some problematic consequences) as well as the dependency on low miner fees and it avoids the privacy weaknesses with on-chain transactions. The power of the arbitrator is now more limited as he has no partial control over the trade funds anymore. Worst case he can make wrong judgements, but then the traders still have time and opportunity to proof their case publicly in front of the stakeholders to convince them to not follow the arbitrators wrong judgement. And most importantly the public Bisq arbitrators will be just one of many possibilities for dispute resolution.

Keeping track of bonded trades

A bond which is sufficient for covering the max. damage of one trade might not be sufficient anymore if the trader is doing multiple trades in parallel.
E.g. A trader locks up 1000 BSQ (let's assume 1 BSQ = 1 USD) for securing a trade with 1000 USD.
If the trader use the same bond for another trade and would scam both traders his max. damage from confiscation is 1000 BSQ but he might have gained 2000 USD.

To avoid that problem we could use the trade statistic (both peers publish that at taker offer time to the P2P network) and add some extra data for the bond there. So the second trader can lookup how many trades have been done in the past with that bond. As it can be assumed that a trade is completed in at least a few days he can get a good estimation of how well secured a bond is. There might be even some improvements possible to mark the completion of a trade as well, but it need to be checked that this is not violating privacy of the traders.

Privacy vs. reputation from trade history

The bond would become an identifying asset which would connect past trades. But it is up to the trader to use either one or a few bonds for many trades or one bond per trade to not lose privacy. On the other side the number of trades would provide some sort of reputation by indicating how many trades a peer has done. It is the users choice what they prefer here: Building up reputation from past trades or privacy.

Costs of long term bonding

For getting a high security against charge back the model might add high costs for locking up bonds to cover the trade amount for longer periods. E.g. if a user trades about 10 000 USD over 3 months he would need to lock up 10 000 BSQ for about 6-9 months. It is an open question if that is a big problem and it would mostly apply to those payment methods which have a long charge back risk period. Compared to the current model it would not be worse even if the bond is not covering such a long period. So that strict long term bonds would apply mostly to high risk payment methods and then a better trade price should pay it off.

BSQ volatility

Another aspect to consider is volatility of BSQ. If BSQ price goes up it comes with the disadvantage to not be able to sell the BSQ quickly, though that might have a positive stabilization effect on the BSQ market. If BSQ price goes down then the bond which was sufficient at take offer time might not be sufficient anymore during the trade. But such high short term volatility spikes should be an exception and a higher BSQ bond should cover that.

Of course that model would be optional to the current trade protocol also because to use BSQ you need to first buy it on Bisq, so there would be a chicken and egg problem if we would replace the current model completely. Also some users might prefer to not need to use another token and stick with BTC only.

The DAO/BSQ is pretty far from development and bonding is basically implemented. I hope we can launch end of August on testnet.

This idea and model is still very fresh and not thought out in all details but I think it will solve a lot of the problems with the current trade protocol and the challenge how to decentralize the arbitration system. Please let me know what you think and if you find any weaknesses or flaws in the concept!

[ripcurlx]

Will the lock time of each bond for offers be defined for each payment method? For some of them it might me quite long (e.g. SEPA: I think it is 13 months until you can't do a chargeback anymore).
So if someone in Europe wants to protect its privacy while trading she will need lots of BSQ which is locked for a time frame that will be affected by price volatility a lot I guess. But still I like the direction of the idea and I think it gives us a lot of flexibility having it ready for implementation.

[ManfredKarrer]

I think longer lock time will be only required for high risk methods like CashApp. Sepa is already very difficult to chargeback anyway (at least if not stolen bank account case - and also there I assume most cases happen in the first 2-3 months).

[sqrrm]

In general I like this direction with buying reputation. I think this would reduce the risk of simple scams. A scammer would have to risk something worth more than the return of the scam to go through with a scam. Even if there is only a small chance of the bond being burnt I imagine it would still be a big hurdle for someone with dishonest intentions. The question is if it's too big a hurdle for the honest users.

To identify the bond I think it would be possible to just sign the bond txOutput itself and not even have a hash in the lockup tx opreturn. We'll still need an opreturn to mark it as a lockup tx though so there is only a small benefit of saving a few bytes by not putting the hash of the pubkey in there.

[ManfredKarrer]

If you don't put the hash of the pubKey into the tx anyone could take a foreign tx and pretend that its his bond.

[sqrrm]

If you prove you own the txoutput with the bond it's basically the same, but you would have to reveal the pubkey for the txoutput.

[ManfredKarrer]

Yes we could use the EC key of the funding txOutput for the lockup tx. The pubKey is there in the blockchain. Though I think if we support a hash we are more flexible what the hash is used for. But maybe its not needed ???

[sqrrm]

I agree that the hash could probably be more flexible. If it's not strictly needed to prove ownership of the bond it could be used for other stuff though if we find a need. Right now I don't really see what though but like you I get the feeling it could be useful somehow.

[ManfredKarrer]

Yes the hash gives more flexibility. For instance when one wants to proof ownership but wants to protect his public key so that not all his bonds get connected (if he used the same) we can add a salt. Other use case might be to combine the pubKey with other meta data so that the bond gets additional context. Even if we don't know yet the use cases it is important that we design it open enough to be flexible to support it in future.

[ManfredKarrer]

After thinking a bit more about the details how to support a long living bond re-used in multiple trades I think that it quite feasible if we don't intend to protect against chargeback risks (because that would require a long locktime - up to 6 months - which makes it infeasible for most traders).

Verification of Bond:

The traders send a nonce to the peer which need to be signed by the private EC key which was the used as input for the bond tx. That way they can be sure that the peer is the owner of the bond.

Keeping track of bond balance: (TradeWitness)

To verify if the bond is not over-used by too many trades we can introduce a new P2P network data object (le's call those objects TradeWitness) which consists in 2 sub objects: One for indicating the start of a trade and one for indicating the successful completion of a trade. Those TradeWitness objects contain the required bond for the trade (e.g. trade amount but can be also higher or lower) and the hash of the tx ID of the bond as well as the hash of the trade ID. Each peer can lookup in his data collection of TradeWitness objects if the bond has sufficient coverage. E.g. If a bond tx has 5000 BSQ as bond and it was used for 3 TradeStartedWitness objects which required bonds of 1000, 2000, and 1500 BSQ and one TradeCompletedWitness object which corresponds to the TradeStartedWitness with 2000 BSQ then the available bond is: 5000 - 1000 - 1500 = 2500 BSQ. The 2000 BSQ is canceled out as it is already completed. The TradeStartedWitness should alos be removed by the arrival of the TradeCompletedWitness.

TradeWitness object:
boolean isTradeStartedWitness;
byte[] hashOfBondTxId;
byte[] hashOfTradeId;
long requiredBond;

Both traders are publishing the TradeWitness objects so cheating of one peer will not help him to avoid that the data get broadcasted. If both are colluding to not send the TradeWitness they are at risk to get scammed by the other peer (no security is provided without bond).

[sqrrm]

Trying to make the data less public

User A wants to use part of a bond as security for an interaction with B, in this case a trade. First A needs to prove ownership of a bond by signing some data with the EC keys used for the bond lockup. This data is the contract. A doesn't want the contract to be public to everyone on the network. A also doesn't want the claim on the bond to be held longer than necessary.

B wants to verify that A is the bondholder and that the contract is correct.

A will sign a hash of the contract that includes the amount claimed towards the bond for this interaction and any other contract specifics and then publish the TransactionStartedWitness

String bondTxId
byte[] hashOfContract
byte[] sigA
byte[] pubkeyB
long timeout

B has the contract and can verify that the contract is correct. B also needs all the other contracts currently in effect for this bondTxId to be able to see the total amount the bond is already covering. A will provide them.

Once the transaction is done B publish the TransactionCompletedWitness

byte[] hashOfContract
byte[] sigB

A timeout would be needed in case B doesn't publish the TransactionCompletedWitness

This method would avoid displaying the amount covered by each bond but the number of transactions per bond would be open.

Bond opreturn salt hash

It would be nicer if bondTxId wasn't public. A hash of a secret salt could be included in the opreturn of the bond transaction. The TransactionStartedWitness then includes the hash of bondTxId + salt instead of the clear text bondTxId. A will send the salt and bondTxId to B who can now verify which bond it is. Over longer running bonds there is still a risk that the salt becomes known to an attacker but the risks are still lower than a clear text bondTxId.

byte[] hashOfSaltedBondTxId
byte[] hashOfContract
byte[] sigA
byte[] pubkeyB
long timeout

[ManfredKarrer]

With the salt we still have the problem that the bond owner can use different salts for different trades and make the lookup for all the open trades where the bond is used impossible.

[sqrrm]

The salt would be fixed for the bond since it's hashed into the opreturn.

[ManfredKarrer]

But then it cannot be changed...

[sqrrm]

Yeah, it's not great but it's an option to keep the bond id hidden for anyone not involved in a transaction that uses the bond.

[ManfredKarrer]

Ok. But then still all traders can see all past trades. Sure better than everyone can see the whole trade history but still not really satisfying.

[sqrrm]

You would still only see that there was a transaction (that could be for any contract, not just a bisq trade) and not the amount, except for those active at the same time that you traded.

[ManfredKarrer]

Sorry for my earlier comments have not read carefully your suggestion. Yes I agree that model should add quite a good protection of privacy. The number of trades/interactions will be visible to all trade peers but not to the whole network. A bond can be renewed after a while as well. I think that is a reasonable solution. In current trade protocol there are also quite a few areas where one can leak privacy (onion address, btc tx graph,...). So I think it will be at least not worse. Maybe we find still better solutions to make the salt more short lived, but I don't have a good idea yet how to achieve that.

[ManfredKarrer]

@sqrrm Could you write up your suggestion in a doc to have it more consolidated than scattered here over some postings?

[chimp1984]

Here is the WIP doc mentioned above:
https://docs.google.com/document/d/1hBA1zQzIToPxV2Wk2ivyooqJzpJaVzFRRtKRaN0ju7M/

[chimp1984]

Here is a new doc: https://docs.google.com/document/d/1sTbm7SuIGQ5HWCwbxYfnklyMHB_-jIr7kAM9-ZSzzH8/

[chimp1984]

If BSQ stakeholding will be mandatory

That was never a plan. The opposite it would be a optional and probably parallel application to current Bisq version. It is also in very early discussion phase and not clear if feasible.

[MwithM]

Closed as: stalled