Feedback welcome to the idea for a off-chain trade protocol:
opened 06:39PM - 23 Jul 18 UTC
closed 09:46AM - 14 Aug 20 UTC
was:stalled
an:idea
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!
2 Likes
Wow! Excellent!
Are any other projects using bitcoin colored coins as described in the BSQ docs? https://docs.bisq.network/dao/specification.html
You describe many excellent opportunities to make the platform safer with BSQ bonds. I see the initial distribution will be to âcontributorsâ as described here: https://docs.bisq.network/dao/specification.html#phase-1
Thanks again and again!
I am not aware of other project using colored coins like we are. Most use it for asset issuance like Counterparty or Colu.
1 Like
I saw someone mention here on the forum that instead of Bitcoin being the âmainâ currency, it should be Monero because itâs more focused on privacy. It got me thinking ⌠Wouldnât it be more beneficial to focus on switching the âmainâ Bisq currency from Bitcoin to Monero? That way itâd be more private and for example those BSQ tokens built on Monero blockchain would be even more private?
Also can somebody explain me, howâs technically possible to build a new coin onto existing bitcoin blockchain? (newbie question) I mean, in order to send you BSQ to someone, you have to have with you also you private key from you BTC address, since BSQ is technically BTC. So imagine someone having frozen funds in BSQ. Howâs this hinder someone to take their private key from their bitcoin address and just transfer their BTC?
Monero is very different to Bitcoin and it would take a lot of dev effort to go that route.
BSQ is a colored coin so technically it is just Bitcoin but gets interpreted differently in the BSQ context.https://en.bitcoin.it/wiki/Colored_Coins
2 Likes
