[bisq-network/bisq] Investigations for a new trade protocol (#5430)

[chimp1984]

Due the high miner fees the life time of the current trade protocol seems to meet its final stages. Beside that there are some new developments and trends which we should consider for a potential redesign of Bisq.
Finally the recent [Bisq fork from some Monero community members](https://github.com/bisq-network/bisq/discussions/5429) adds pressure to find a solution as in case their fork will end up in a successful project it might take away a big chunk of the XMR trade volume which accounts for about 80-90% of the revenue of Bisq. Such a reduction in volume could render Bisq unsustainable.

I was researching for alterantive trade protocol ideas over the past weeks (and with less intensity over the past years).
Here is a rough preliminary summary of that journey.

## Bisq's attempts for a new trade protocol

- [Off chain trade protocol](https://github.com/bisq-network/proposals/issues/118)
The core idea to separate asset transfer and security is still a goal. Though the original proposed idea how to achieve that by tracking reusable BSQ bonds is probably not feasible and the idea is dropped.

- [Reduce trade protocol to 1 single transaction](https://github.com/bisq-network/proposals/issues/279)
It seems the most feasible approach but does only win us some time and even 1 tx might be too much mid-term.

- [Off-chain trading using a lightning network of BTC & tainted BSQ](https://github.com/bisq-network/proposals/issues/312)
Very interesting and sophisticated approach from Steven Barcley to move the trade protocol to a custom LN. 

## New developments and trends
- The potential replacement of traditional Fiat money with Central bank digital currencies (CBDC) can disrupt the primary use case for Bisq as Fiat exchange
- Automated marker maker models for solving the liquidity problem and improving usability are superior to a barter model
- Atomic cross chain swaps remove requirement for collateral and any trusted third party
- Layer 2 solutions for avoiding high miner fees and getting instant transfers
- Side chains or other blockchains for enhanced and custom smart contract functionality

## The role of CBDC vs. traditional Fiat
I assume traditional Fiat with banks as we know it today might not be much relevant anymore in the mid-term future.
Most countries are working on their CBDC projects and some like China have already rolled it out in large scale pilot projects and will likely reach mainstream adoption and maybe even international adoption rather soon [1]. They are pushing hard to use it for international trade and combine it with efficiency improvements and cost reduction for cross border trade and payments. It is based on a permissioned blockchain infrastructure with bridges to permissionless cryto currencies (currently 12 are supported [2]). They even target atomic swaps between their permissioned chain and the persmissionless ones.
>From what I have read so far it looks like integrating with any not supported coin can be done as a chained swap (e.g. XMR -> ETH -> YUAN / YUAN -> ETH -> XMR). There might be some friction and gates (KYC) for the supported coins but so far such is not visible and hopefully be not become a majore hurdle. In short the Chinese model seems to be easy to get integrated in a DEX, excluding the last hop to the CBDC on the permissioned layer.
>From the EU and US projects I have not found anything more concrete yet but reading their highly contradictional and problematic requirements [3] (e.g. applying financial policy like negative interest rates and demurrage to the base layer) I doubt they will succeed and find acceptance. Also as centralbanks, banks and government bureaucrats are not famous for getting anything done in the technology field I doubt they will deliver anything solid.

With that in mind I think crypto to cryto exchanges will come much more under regulatory pressure and atomic cross chain swaps or other strong DEX models will be required for maintaining censorship resistence.
  
## Automated market maker (AMM) based DEX
Liquidity is a main problem for any DEX. An approach to solve that are liquidity pools. [Uniswap](https://uniswap.org/) is one of the most famous examples for that. I have not looked closer into the details but it is obvious that usability is superior compared to the pure P2P based barter model used in Bisq where the "double coincidence of wants" is a limiting factor. It requires more complex smart contract capabilities as available in Bitcoin (at least I would not know how to get AMM implemented in bitcoin).   
So I think for a Bisq redesign a solution which enables market maker pools would be superior to a pure P2P barter exchange model.

## Atomic cross chain swaps
The idea is out since several years but now it seems to get more traction. I want to give an overview of some promising projects.
One downside with the atomic swap model on the base layer is that it requires still 3 transactions (maybe it could be reduced to 2?), so with high miner fees that will be an issue for adoption at least for lower volume trades. Transaction time is dependent on block confirmation time, so it is not a fast/instant exchange. Beside that you need to observe both blockchains, which comes with some storage/bandwidth/cpu costs or if that is delegated to public nodes with a trust/privacy/security trade off.

### Mercury
This was the first atomic swap project [4] I am aware of, but it never took off and it is not in operation anymore. I just wanted to mention it as is shows that a technically and conceptually sound project does not guarantee success and user adoption. 

### Farcaster project
Farcaster [5] is funded by the Monero community and intended to support many different blockchains. They work on a reference implementation in Rust for a BTC - XMR swap. It is very protocol driven and the authors have several years of track record to work in that problem field. It is not based on HTLC (Hash Time Locked Contracts) but on Adapter Signatures and use zero knowledge proof.
Its hard to estimate when it will become production ready but could be in 3-6 months. 

### Comit
This startup [6] has implemented prototypes in Rust for several atomic swaps: XMR, ETH, GRIN, Liquid (work in progress). Not sure if they did LN as well so far but I assume that is for sure on their list.
I think they used a HTLC approach for the chains where that was possible and adaptor signatures for XMR (have not looked closer but I guess their work is based on the model of Farcaster).
Very ambitious project with interblockchain communication as long term goal.

## Layer 2 solutions
Using Lightning network for a DEX comes with some challenges. There is no multisig support. Channel capacity is still not that high. Privacy for high volume transfers might be reduced as number of channels is more limited. Security for large volume transactions might not be strong enough still (edge cases with channel closures). There is lot of development ongoing and with new Bitcoin features like Schnorr LN will see bigger changes as well. There are layer 2 networks for major chains like ETH but its not universal for the multitude on altcoins, so any solution would be probably limited to those few chains (at least if swaps are the main use case). All that said, I am not following very closely LN, so those conclusions might be a result of lack of knowledge...

### Atomic swaps via Lightning network
Atomic swaps between different Lightning networks (BTC, LTC) or Lightning network and its base layer (submarine swaps) [7] are implemented since a while but it seems the use case to swapping BTC to LTC has limited demand. More interesting coins like XMR cannot be swapped that way. 

### Statechain
A Layer 2 solution using adapter signatures for moving an utxo in a state chain [10]. Has some similarities with LN and Liquid but different trade offs. 
There is a [new project](https://mercurywallet.com) which has implemented that concept. Could be probably used for atomic swaps between multiple statechains in diff. base currencies, though not sure about the requirments if Monero for instance could work as base layer. 


## Sidechains
Another approach are side chains. Unfortunately for 2 way pegs there is no "perfect" trustless solution and maybe never will be as it would contradict the philosophy behind sidechains to be risk-free for the main chain.

### Liquid
I have not looked closer into Liquid so far. But my main concern is that Liquid as a federated sidechain where the peg-out depends on one of the federation members might not find acceptance among Bisq users and from my perspective is problematic regarding censorship resistence. Though of course the immense brain power from Blocksteam and the wide range of innovation coming out if it is a strong reason to look closer into it to see if there is a potential use case for Bisq. 

### Rootstock (RSK)
Similar to Liquid its a federated sidechain thought it seems they worked very hard to reduce the risks and required trust to a high degree (using a layered combination of several aspects like merged mining, hardware security module, federation, etc.)
It is a huge ecosystem with a rich set of features (ETH compatible smart contracts, dns, storage, market place,...). It would require much more time to get deeper into it.

### Tari 
Tari [8] is a merge mined Sidechain with Monero using Mimblewimble for asset issuance and fast transfer. Use Tor by default. Founded by Fluffypony (Monero core contributor). 
Tari will also support atomic swaps between itself and Monero. Still in development (testnet). Have not looked closer but seems like a promising project. Not sure about smart contract capabilities, seems more to be tailored for asset issuance.

### Spacechains
A one way pegged sidechain concept by Ruben Somsen [9]. In discussion with him about potential applications for a DEX use case.

## Others:
There are a lot of DEX projects out and its very time consuming to figure out which ones are worth to invest more time. Here are just a few which caught my attention.

- https://boltz.exchange: DEX based on LN: 

- https://sovryn.app: Based on RSK. Automatic maker maker dex, loans,...

- https://www.stacks.co: They use the Bitcoin blockchain for security (root their blockhashes in a tx). Earlier it was based on proof of burn then they moved to a staking model. They have a smart contract language and support child chains for scalability. Did not look closer to get a clear opinion.

- https://www.thorchain.com: Shilled a lot and doing heavy annoying PR... might have interesting concept behind, but PR turned me off too much to invest more time. Seems to be based on collateralized liquidity providers and swaps on their native chain.

- https://tendermint.com / https://cosmos.network : Popular smart contract blockchain SDK used by several interesting projects like https://lazyledger.org. Uses child chains for scalability. 


## Conclusion
Unfortunately I have not found any convincing solution so far.

Atomic cross chain swaps are very promising but usability will not be that great and miner fees in the case of BTC will be an issue. In the context of competition with AMM based DEX projects I am not sure if they will manage to bootstrap.
Using a custom blockchain comes with the friction that a token is usually needed for using that DEX. There are many projects out in that field which are based on collateral which comes with volatility and liquidity risks. 
Using a federated side chain reduces censorship resistence and usually rely on some IOU issued on that sidechain for being used as collateral in a DEX use case, so that would add another layer of risk and trust to the IOU issuer.

For securing a trade collateral seems to be the most common solution if atomic swap cannot be done. If the collateral is a DEX token the volatility and systemic feedback risk is rather high (e.g. if there is a hack the token might crash to zero very fast, so collaterals will not provide security anymore and adding more damage). Using BTC as collateral would be much more acceptable and more decoupled from the DEX.

So what would be the requirement for the "perfect" DEX?
- Privacy protection, no trusted entity required
- It should enable AMM models to combat the liquidity problem
- It should be based on atomic swaps but does not come with high miner fees (e.g. do the BTC part on LN and the XMR part native, not sure if thats feasible...). Requiring a layer 2 solution adds friction as well. 
- Second best model is to separate asset transfer with security. Security can be flexible and adjusted to context and user preference. Security by collateral comes with high capital requirements and locks out many newer users. Having flexibility where reputation or other features can be mixed in could reduce that burden. If collateral is used it should be in BTC or the base currency of the DEX but not a DEX token. 

Maybe we can transform the idea of Steven Barcley (https://github.com/bisq-network/proposals/issues/312) to a model where BTC can be used in LN instead of BSQ. 


## References:
[1] https://bsnbase.io, https://antchain.net/, https://trusple.network, https://www.youtube.com/watch?v=v_At6UHMGOc
[2] https://bsnbase.io/g/main/serviceNetworkLeague
[3] https://voxeu.org/article/design-choices-central-bank-digital-currency
[4] https://github.com/mappum/mercury
[5] https://github.com/farcaster-project, https://eprint.iacr.org/2020/1126.pdf, https://cryp.ee, https://ccs.getmonero.org/proposals/h4sh3d-atomic-swap-implementation.html
[6] https://comit.network/
[7] https://blog.lightning.engineering/announcement/2017/11/16/ln-swap.html, https://wiki.ion.radar.tech/tech/research/submarine-swap
[8] https://www.tari.com/, https://tarilabs.com/
[9] https://www.youtube.com/watch?v=N2ow4Q34Jeg
[10] https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39






-- 
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/bisq/discussions/5430
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20210421/8eef9e09/attachment-0001.htm>