[bisq-network/proposals] Investigate alternative implementation for bisq (as basis for V2 / off-chain trading) (#125)

Wed Nov 13 05:35:12 UTC 2019

> I have several serious concerns with how that proposal have escaped it's initial goals.
> 
> Building on top of Bisq v2 is premature
> The original goal was a feasibility study for a potential new trade protocol (Bisq v2).

This is not accurate. The goal is to find out wether or not an implementation in another language (other than java) would be possible at all. Now - when the details of V2 are figured out - we know we have that option. Before it was conjecture.

> Further the initial view that Bisq v2 requires a hard fork must not be taken as “fact” but as first "educated guess". It might be that we find ways to integrate it in Bisq v1 and/or deploy it without hard fork as we found a way to deploy the new trade protocol (1.2) without a hard fork.

I am aware that this is based on conjecture. I even write: 
> It is _very likely_ that off-chain trading will not be backwards compatible.

This is not a proposal to do V2 in Rust. This is a proposal to find out wether or not V2 in _any_ language other than java could even be considered (once conceptual details have been decided).

> Moving goal posts
> As far I understand the original goal has changed in the meantime (not documented in that proposal) and the current goal is to do a full re-implementation of Bisq.

This is not accurate. This proposal has not changed. Me and @wiz have however opportunistically used the resulting code base for other things than was originally intended that has already provided significant value, even though this was just a POC:
- Implementing a tool to monitor uptime of seednodes
- re-implement markets API
- do a feasibility study on creating a stand alone android app

So there are no moving goal posts for this proposal. All concerns regarding re-implement V1 should be addressed in the [android proposal thread](https://github.com/bisq-network/proposals/issues/139) as they are not relevant for this proposal.

> How to integrate the DAO?
> I know that @bodymindarts states that reimplementing the DAO is not a goal. But thinking the consequences of that statement further I see serious difficulties.
> If the DAO is not supported at all we exclude the traders from the DAO ecosystem and we amplify the role of the trusted and centralized BTC donation address holder who need to do the work for converting BTC to BSQ and burning them instead of the users who use BSQ for trade fees. So basically we are damaging our goal and achievment that users pay their trade fee in BSQ to have a decentralised form for distributing the revenue to contributors.

This is an excellent point so I would like to clarify. While I consider having 2 implementations of the DAO consensus rules quite risky I don't see an issue with having multiple BSQ wallet implementations. Just like Bisq itself contains a wallet implementation for BTC but doesn't implement all consensus rules (ie it is not a BTC full node) it should be no problem to integrate a BSQ wallet (for trading fees) _without_ re-implementing the DAO.

If you think about the use cases the way ppl use a trading app is completely different than how and when they need to use the DAO governance features. I see no reason that this functionality should be co-located into 1 app.

> Splitting the small developer community and dev resources

This point is not relevant here. 1 developer is enough to do a feasibility study. Please move the comments relating to a potential re-implementation to the [android thread](https://github.com/bisq-network/proposals/issues/139)

> Missing strategy
> I don't see any clear strategy plan. Do you suggest 2 parallel implementations? Or is the goal to replace the java implementation? What are the expected benefits and what are the costs? Do you think a reimplementation with one core developer who is learning a new language and doing most of the work alone will lead to significant better code quality?

So in general this proposal is intended for information gathering to be able to make a more informed decision when the time to implement V2 comes. Forming a concrete strategy for V2 at this point is hard as there are so many unknowns conceptually.

> one core developer who is learning a new language

I don't think this point is relevant as the POC is about feasibility but I would like to mention that rust is not new for me. 2 years ago I was a core maintainer of one of the [largest open source rust code bases](https://github.com/habitat-sh/habitat).

> Risks with dependencies
> I estimate the risk of dependencies provided by large corporations or projects in Java is lower than the risk to use dependencies from rather new languages like Rust with a smaller ecosystem where some critical infrastructure libraries are provided by small teams or even single developers.
> 
> Being conservative and building on top of old and "boring" technologies is the better choice for security critical projects like Bisq.

This may be true in general. However I think for the most critical security related dependency that interfaces with the private keys this is not the case. https://github.com/rust-bitcoin is actively developed and maintained by a number of bitcoin-core devs with very high reputation in the Bitcoin space.
Rust is even being considered to be included into bitcoin-core https://github.com/bitcoin/bitcoin/issues/17090. The same cannot be said about the JVM or BitcoinJ.

> Some comments to your "Major Triggers":
> The current state of the code base has a lot of technical debt

I think most of these points are better addressed in the (android thread)[https://github.com/bisq-network/proposals/issues/139]. 1 dev is enough for a investigation / POC.
> 
> The most important dependency of Bisq (BitcoinJ) is unmaintained and untrustworthy. There is no alternative in the JVM ecosystem.
> 
> As soon we have the resources we will consider to implement alternative to BitcoinJ, though there are not really a good one out unfortunately. Neutrino was at least a year ago not feasible (See our study at: bisq-network/bisq#1062 (comment)) and using Electrum is the most likely choice. I don’t see how using the JVM limits us here. I am not aware of a Rust SPV model which would fulfil Bisq's requirements (client side bloom filter still does not support unconfirmed txs as far I am aware).

There are implementations of bip 157 / bip 158  (in the rust-bitcoin org as well as bip 37 [here](https://github.com/dongcarl/rust-bitcoin-spv)

Its great that research this research has been done. This proposal adds to that research and allows us to make a more informed decision about how to deal with this highly significant security concern.

-- 
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/proposals/issues/125#issuecomment-553247148
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191112/b673330c/attachment-0001.html>