Bisq 2.0 - A multi-protocol DEX (working title Misq) #330
Comments
Next stepsTried to get a bit of a plan what needs to be done if the proposal finds support. Also did a very rough estimation which ended up in 200 person days, which would be about 3 months for 3 full time devs. Probably its more, but too early at that stage but I guess a range of 2-6 months for 3 full time devs might be realistic. Validate concept
Bootstrap project
Design
App infrastructure
Persitence libP2P libMessage boardWallet, blockchain
Protocol, security
Dispute resultion
DAO
|
chimp1984
changed the title
chimp1984
changed the title
|
It sounds very ambitious! Positives:
Concerns:
|
I bet you will beat me, at least you produce less bugs ;-)
The modular approach should not be visible to users. For users its just one app where they can enable features (chains). But sure not much worked out yet how that will work. Generally UX is probably a main issue. Not sure how it can work out to make it easy for users to select the options without the mental costs of understanding all the context and trade offs.... So I think that might be actually the biggest risk and we should try to work on that first before getting any deeper on other technical details. |
|
I tried to sketch a bit the basics of the UX and to my surprise it might not be that hard and different to the current model. Sure it adds more options and with that comes more complexity but a good UX designer can hopefully design it so that it becomes acceptable. The step based approach is just an example, could be done differently as well. Some options might be also set at initial setup or in preferences. The plugging in of wallet and blockchain infrastructure could be done dynamically, so that a user gets their BTC wallet setup once they choose to use BTC. Create offer
Review offer:I ask for 500 EUR and offer 2 XMR.
Expected fees: Depends on choosen protocol (5-25 USD). Post offerOffer gets published to P2P network Offerbook
Take offer
If we permit custom free text data is an open question and might end up being abused for spam, scams, etc. We could give mediators a moderation right so that they can mark such offers for getting blocked and allow users to report such offers. Benefit would be that it adds flexibility and allows new niche markets where dev effort would not be justified by low trade volume. |
|
I like the ideas a lot! I think it is a good idea to focus on protocol and API, but we need to make sure to start soon with developer relations/documentation, development funds?,... for devs to come up with slick UIs or other implementations leveraging the API (I think 0x.org has done a good job in that regard) My concerns:
|
|
I like the idea, especially making it modular so that it can evolve and grow in the future while avoiding bottlenecks. It makes a lot of sense to separate the base layer modules from the trading mechanism. But... my concern is that it seems very ambitious and will require a lot of effort and time to build, even modules that already exist in Bisq. Why not re-use the Bisq P2P network, offer book and direct-message system? We could have a simple P2P message board for offers in days using existing code. Just create a new market on Bisq (call it "experimental") and remove the fees required to post an offer, change the payment methods so that both sides are fiat (ie: off-chain off-Bisq) and eliminate the security deposits... voilà, you have an instant tor-based p2p message board and offer book! P2P network layer -> you already have everything you need in Bisq 1.6.2 Security modules -> you have enough to start with in Bisq 1.6.2 There's even an informal market to buy small amounts of BSQ and BTC on keybase: https://bisq.wiki/Informal_Market_for_Small_BTC_Trades#How_to_access_the_Keybase_channel Why reinvent the wheel? |
|
|
OK here is an even more radical proposal that would minimize work and time needed: have everything that does not need to be in Bisq outside Bisq. Use Bisq only for what it does best: security features, dispute resolution and DAO governance. P2P network layer: Don't use Bisq. Use bittorrent. Dispute resolution service: use Bisq mediators, arbitrators, DAO refunds, etc as they are right now. This could even be done TODAY without writing a single line of code. How?
Obviously the amount of BSQ locked up would need to be large enough in relation to the BTC-fiat trade (50-80%?) to act as a good enough security deposit and deterrent in case of dispute. During the 24 hours that the BSQ trade lasts you can do as many BTC-fiat trades as you and your counterparty want, thus minimizing the number of on-chain txs. Obviously this would work even better with small UX, software adaptation and training mediators to allow this type of trade. We could even have DAO-bonded market makers. But the point is that it would work even without all of that to solve the problem of reducing expensive on-chain transactions while keeping security NOW. Not in a year or two of development. In fact I've created a proposal for this: #331 |
Yes it should be done in parallel, so Bisq just continues as it is until the new project is mature enough to take over and even then the old Bisq could be kept running if there is demand.
Not so sure anymore if a renaming is a good idea, as it might confuse users and we managed to build up a very valueable brand. But maybe its good to have a working title to not confuse normal Bisq with the new one...
Yes I think those old OSGi like heavy weight frameworks have been a big failure. I mean module just from a conceptual point of view. An entity doing one clearly scoped thing and not more. This can be a package in the code or a module as in Bisq the dif. modules or a library project or even written in another language and run as independent process and interact via TPC channels using ZeroMQ or the like. At the moment I try to focus on the high level picture and concept to not get lost in details, but there will be quite a lot to fine-tune about the architecture like choosing the message format, module APIs, etc.... |
I think that this proposal would be very similar to Thorchain model. BSQ would play the role of their token Rune. The difference, of course, is that unlike Bisq they cannot handle fiat trades. |
|
I think the idea posted at #331 is quite interesting and can help to get further here as well. I think to have an iterative process with continuous results to the end user is very important to avoid to get lost and see early what works and what not and be able to adjust. As it seems the general idea has found support I started a Bisq project at bisq-network/projects#51 to get the first milestones bootstrapped. Beside that what are the next steps?
Regardig AMM: I think the overall function and benefit are similar, and then its a UX challenge how to reduce complexity for the liquidity provider. An important addition are arbitrage traders/bots who make sure that Bisq's internal price anomalities are getting dissolved fast. The price finding in AMM is not that optimal IMO and comes with costs and risks. In the bot use case the price is not determined by an algorithm which requires arbitrage traders to get adjusted to external price levels but relies on price feeds which can be defined by the bot operator, thus there is no single point of failure to the overall system in case the price feed gets corrupted (though to the bots using the manipulated price feed). Price aggregation as we use in Bisq can reduce that risk. Also the AMM models have issues with under-utilisation of capital. So all in all I think its not that efficient and the main success comes from the simplifaction of the mental model. 0.3-0.6% trade fee is also not really low for an automated system. Here is a good overview about the Uniswap model: Liquidity providers get UNI tokens in return to their provided asset (ETH, ERC20 token). Once they take out their provided liquidity (as % of the pool, not as the nominal added amounts) they burn the UNI and get the earned fees (0.3% for ETH-ERC20 or 0.6% for ERC20-ERC20 trades). So there is volatility risk (impermanent loss) and the risk that the internal token is used as collateral and could lose value in a black swan scenario. Here is a good write up about Impermanent Loss: It seems the volatility risk is not reflected in the trade fees. A highly volatile asset earns the same trade fees but comes with much higher risk for impermanent loss. Maybe I miss some important difference, so if you are more familiar with those models and automated trading, please add your view on that. |
I think I never found anyone complaining about this, but you are right. When trying to provide liquidity for rskswap I knew I would not want to provide for the DOC/RBTC pool but for the BPRO/RBTC pool because of volatility. |
Investigating to really understand those models takes time and effort. Most users probably don't invest that much money that it justifies a lot of due dilligence effort. Thats one reason why regulation tries to protect retail investors as its much easier to scam 10000 small investors than to scam 1 pro invester who spends weeks for due dilligence and comes with a lot of experience. |
I agree with this. Currently trades done on Bisq have a reduced community / social aspect to them than is present on Bisq's social platforms. I think there is lots of potential to develop this and utilize Bisq's community strengths. Having multiple protocols on one platform sounds fantastic. For example it would be great to use Misq to provide liquidity to a BSQ / BTC pool, do regular small EUR trades with no coiners for BTC, and also larger collateral based trades to purchase some BTC. My initial concerns reading this would having everything on one platform might lead to a reduction in privacy. Using Keybase to sell small amounts of BTC has been great. But I am still not entirely happy with having to expose personal details each trade. The trade off is helping someone else get some BTC and making a small amount of profit. Keybase not being part of Bisq is also good as it creates an additional step between Keybase username and Bisq onion address. It would be great if Misq could keep user privacy whilst retaining the benefits that would come from trading based on reputation.
My concern with this, and to be fair the buy-bitcoin Keybase channel, is that it would be easy for a disgruntled trader to post identifying information on a thread, or even on external website eg Don't trade with Joe Blogs he is a scammer and stole all my Bitcoin etc |
|
Do you mind if I make a social trading proposal as an expansion to this, I already have lots of details ready (protocols, utility, design specifications) and been wanting to do one for a while? @chimp1984 |
|
Hi @Mentors4EDU, sure please share your ideas! |
|
Submitted, I tried being as detailed as possible! |
|
How I imagine a modular architecture for Misq - multiprotocol Bisq 2.0 A shared marketplace, order book, communications protocol... which can then connect to many different trade protocols. All resources can be pooled for the shared infrastructure, but then each project can work on their own version of the trade protocol, wallets, etc.. and experiment freely with on-chain, off-chain, lightning, atomic swaps, different base currencies, different multisig systems, arbitration, moderation, MAD, unsecured, etc... obv this is just a rough approx by a non-dev... I have a lot of stuff missing (wallets? price-feeds? blockchains? etc) |
|
Hi @chimp1984 thanks for this. It looks like a very exciting development. Closing as approved. Links to the related projects that are the outcome of this propsal are:
Please also see the work in progress Misq repository here: There is also discussion about the project on Bisq Keybase on the channel bisq#misq-dev |
The intent here is to establish and refine a Ubiquitous Language (in the DDD sense) that can help guide our efforts in building out the ambitious feature set of Bisq 2.0. The terms laid out here attempt to cover most of the points mentioned in the original Bisq 2.0 proposal at bisq-network/proposals#330 and also include some original insights that emerged during the process. The document is and will remain a work in progress, but is now in good enough shape to share and get feedback on. Fixes #31
Overview
The suggested new architecture supports multiple trade protocols and security mechanisms as well as multiple blockchains.
The separation of the security mechanism and the asset transfer provides a lot of flexibility to adjust to users needs and preferences.
The problem of market fragmentation can be mitigated by supporting multiple protocol and security options and allow the taker to contact the maker for negotiation.
As the network infrastructure provides features which can be utilized by a social media and messaging application we could integrate that aspect to some extent to add a "social trading" experience as well to gain a new tool for an alternative security module (utilizing social graph, reputation).
Both the approach to allow an off-chain protocol and to add the social aspect would help to distinguish Bisq from the competitors in the DEX market.
As the architecure is very different to the current Bisq model I think it justifies to start over with a completely new code base.
Base modules
P2P network layer:
Message board
Direct communication channels
Security modules
Trade execution
Dispute resolution service
Using external wallets via RPC
Blockchain data provider
API and protocol driven
Bisq DAO
The Bisq DAO can be distributed to the supported blockchains in the way that BSQ owners can burn BTC based BSQ and by providing the proof of burn they can request reimbursement on the side-chain DAO. Any side-chain DAO will start with a new genesis transaction. This is based on burned BSQ from some Bisq core contributors so the initial distribution is somehow reflecting the voting power distribution on the BTC based DAO.
One can also go back to the BTC based DAO by the same burn-issuance swap model, that should guarantee that the value of a BSQ on different chains is roughly the same. It might be useful also for improving privacy by swapping between chains (not perfect but increase costs for chain analysis mercenaries).
All that will not require any code change beside the required adoption to the blockchain parameters. The total amount of BSQ will stay the same of course, it is just distributed to multiple blockchains.
Trade fees, revenue
How to deal with trade fees in the overall model is an open question, but I am sure thats the least problem to solve ;-).
Social trading
I think the social aspect is heavily under-utilized and would be something which distinguishes Bisq strongly from the large group of competing DEX projects. As privacy protecton is the core and comes by default, this might be also a potential alternative to some social media platforms. Though being aware that this is a huge space on its own we should focus on what is most useful in a DEX and cryptocurrency context. I have not thought much about it as it is a rather new idea. A main utility could be that it can be used to provide some level of trust (users have built up trust by having conversations and thus agree on lower security requirements making the trade cheaper and reduce friction).
As we see in the OTC trades on keybase users are ok to trade small amounts for weak or nearly no secruity.
This aspect can be seen as optional and low priority and probably requires more thought and discussion to see if it makes sense.
Roadmap
I am aware that this is a huge project and have not thought about any concrete plans how that could be implemented (beside that I worked on some prototypes specially on the p2p side). So if it is feasible to get there is another open question and with our shortage on dev resources I have my doubts. But lets see, maybe some new devs get attracted ;-).
One approach could be to develop in parallel a Bisq version based on another blockchain (seems Liquid is the most promising candidate so far). Once we have that, users have the choice to use Bisq or Lisq (the Liquid based Bisq). Later once we have implemented the Misq project it will help to reduce the effort to integrate Liquid into Misq.
Why not go full atomic cross chain swaps?
It is technically and conceptually probably the most convincing approach but there are some issues also which I think might be a barrier for wider adoption, specially in a P2P context.
So to build a DEX based only on atomic swaps would come with its limitations. Beside that the adapter signature based approach (required for XMR/BTC swaps) is still in developement.
In contrast the above model would add a lot of flexibility and could serve many different use cases including atomic swaps. A no-coiner could get their first BTC and pay with Paypal to someone they met on the message board and have built up sufficient trust to engage in a small amount trade. Others can choose an atomic cross chain swap with a large trade amount and get best security and are fine to pay a bit of miner fees. Others have coins on one of the supported blockchains like L-BTC or LTC and use the normal Bisq model with security deposit. Monero folks can swap their XMR to anything including fiat or Havana cigars by choosing the security module they prefer.
Collateral based protocols
Note that there would be 2 models of the collateral based protocol.
One is the same as in Bisq where the traders pay the security deposit in the currency of the choosen blockchain (e.g. BTC, L-BTC, LTC) and the seller use the asset to sell as collateral which will be transferred to the peer.
Then there is another model which keeps the collateral and transfer separate.
If the transferred assets do not match that base currency they need to choose who pays first. The one who pays last will have to lock up the equivalent of the trade amount using the base currency plus some security deposit (e.g. 10%). The one who pays first only needs to lock up the security deposit (e.g. 10%). After both have exchanged their assets via any arbitrary channel (can be anything, EUR <-> USD or apple <-> banana) they sign the payout tx to get refunded their collateral. The drawback is that the one who pays last requires a larger deposit, but they can choose who want to play that role and it might be reflected in the trade price. So there is some flexibility and the extra capital requirement can be priced in so market makers might be motivated to play that role for some premium.
The text was updated successfully, but these errors were encountered: