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

Wed Nov 13 04:25:58 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). But we don’t know yet if Bisq v2 is feasible from the conceptual point of view and the security model as well as we don’t know if the changes for the economic model of the DAO would carry too high risks. I think the right process would be to solve the conceptual challenges for Bisq v2 first and only if those are solved to start thinking about the implementation details (e.g. which language to use). 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.

### 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. As far I am aware @bodymindarts states that reimplementing the DAO is not a goal but he also told me initially that reimplementing Bisq and the trade protocol is not a goal and the goal posts have moved in just a few weeks. 

### Multiple implementations are not a good idea for consensus systems

Bisq is a complex system of different levels of consensus and compatibility requirements and we have seen already in the recent issue with the requests for 9 MB of Tradestatistic data from risq nodes that this risk is real. 

We have seen from the Ethereum space that having multiple implementations can cause severe problems and also Satoshi was strongly against alternative implementations of Bitcoin and still up to today no miner uses alternative implementations to Bitcoin Core for mining as the risk is too high. 

The spectrum of that consensus and compatibility requirements are difficult to see and understand. It can reach from relatively soft cases like the requirement that nodes are persisting data and using resource files for optimisation to not over-consume resources of other nodes (seed nodes in that case) to hard cases like the DAO consensus system where in the worst case a fork can destroy the value of all BSQ stakeholders. 

## 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.

Shipping the DAO java code inside of risq would add a really heavy resource burden as you need also the JVM and you run the p2p network, BitcoinJ wallet and much more, basically the full Bisq app. So all the promised benefits to have a faster and more light weight risq app would get inverted. So I don't see a feasible solution for that problem. 

Reimplementing the DAO is an absolute no-go from my point of view as the risk to break it is way too high and the whole project value is on stake here. So any BSQ stakeholder could lose all their BSQ holdings. I certainly will not take that risk.

### Splitting the small developer community and dev resources
We don't have enough dev resources to improve Bisq as we would like to and to add new features. With losing some of those dev resources for an alternative implementation we would reduce that work force even more. 
We should not be tricked by seeing a quick prototype. I assume everyone is familiar with the 20/80 rule. Bisq had when it started 6 years ago a working trade protocol prototype with p2p network and bitcoin wallet in 3 months out, but it took another 3 years to get it production ready for launch. 

### 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?
I would estimate a high quality reimplementation to take 5 high skilled devs (who have already experience with rust) about 6-12 months. 
And even then I assume there are high risks to be compatible and do not cause lots of consensus issues. And excluding the reimplementation of the DAO. I am sure with an estimated 450 000 - 900 000 USD budget we can do more then simple provide an alternative Bisq version in another language. 

### 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. 

### Some comments to your "Major Triggers":

> The current state of the code base has a lot of technical debt

To reimplement a large and complex project like Bisq without the risk to end up with a similar level of technical depts require a rather large team of highly experienced developers doing TTD or pair programming. So far I have not seen any of those requirements fulfilled in the risq project (learning a language by building a financial app does not seem to me the right approach). So far I see @bodymindarts is the main developer with the huge majority of commits. The stats at https://github.com/bodymindarts/risq/graphs/contributors shows a much worse dev distribution as we have in Bisq (https://github.com/bisq-network/bisq/graphs/contributors). Sure it's very early days and I don't want to overinterpret that but I also assume it will be very hard to find experienced Rust developers (not those many who are in the process of learning it).

> 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: https://github.com/bisq-network/bisq/issues/1062#issuecomment-446755367) 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).

> Integrating an API into the current Bisq code base is a significant challenge.

This is a misleading statement. I just provided a GRPC prototype with placing an offer via API in roughly 1 day. The reason why we did not get much progress on the API side is a complex mix of lack of reviewers/maintainers and lack of capability of the project devs to do the required refactoring which led to the unpleasant deadlock situation we have and it is a pity that this causes so much mis-interpretations and bad reputation. 

-- 
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-553233280
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191112/cda56dae/attachment-0001.html>