Off chain trade protocol using BSQ bonds #32
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.
The current on-chain trade protocol with the 2-of-3 MutiSig deposit tx has several disadvantages:
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 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:
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.
This model of bonding could be used for other use cases as well:
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.
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.
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!
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).
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.
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.
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.
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.
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).
Trying to make the data less public
Once the transaction is done
A timeout would be needed in case
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
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.