Remove DAO [$600] about haveno

[niyid]

Looking at this. Should be ready within a week.

[l0nelyc0w]

Just a quick update, premek has done a lot of work removing DAO and BSQ references and cmdline args and also fixed the first issue mentioned above (when you try to create a new altcoin account the list is empty in AltcoinAccountView).

We are still working on the rest of the issues.

[l0nelyc0w]

Hello, I would like to try to give this issue it a try.
I created a new account in order to maintain my privacy. As such I am not able to show any project portfolio. I had thought of forking Bisq to make it monero-based instead of btc-based a couple of months ago so I am very happy to see the same idea getting traction!

[xrv0]

I agree. You can always go back and look at the code if you really need to. Unused code should be removed.

[l0nelyc0w]

Another quick update, we are still working on the issue, premek removed some more BSQ references, while I have been trying to debug a problem regarding the reservation of an incorrect amount of XMR when creating a new offer.

[github-actions]

There is a bounty on this issue, the amount is in the title. The bounty will be awarded to the first person(s) who resolves this issue. Read the full conditions in the 'bounties.md' file. If you are starting to work on this issue, please write a comment here, so that we can assign the issue to you and avoid duplicated work.

[erciccione]

@haveno-dex/developers this issue is open for assignment.

[premek]

I think @woodser wanted to keep some level of compatibility with upstream. should the dao code be removed or hidden behind a feature flag or what exactly is the idea here (if any)? thanks

It's already removed from the GUI, right?
-- EDIT: it's hidden with the daoActivated flag -- probably a good place to start exploring what needs to be removed

[woodser]

The entire DAO can be removed.

[erciccione]

@l0nelyc0w i assigned this issue to you. Please keep us updated :)

[l0nelyc0w]

On Sun, May 16, 2021 8:16 am, erciccione wrote: @l0nelyc0w i assigned this issue to you. Please keep us updated :) -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #13 (comment)

I have started working on the issue. I will keep you updated :)

[l0nelyc0w]

@erccione Local Haveno testnet and local Monero stagenet ready.
I have started working on the issue. I will keep you updated!

[l0nelyc0w]

Progress Update:

Pushed a commit on my remote to avoid data loss as I have removed a lot of code related to dao and bsq. Maybe the initial approach to remove the whole dao folders and all files that were exclusively related to dao/bsq wasn't "the right way" but after working some days in debugging the errors it really helped to get familiar with a lot of the related code.
A lot of code was removed without being commented out (currently removed dao codebase amounts to ~48000 lines) but code that was not exclusive to dao will be reiterated and verbose comments will be provided. Code related to bsq spans multiple modules and layers from core dao, to offers views and UI.

[l0nelyc0w]

After figuring out all the interconnections, a more top-down approach may be followed starting by removing the dao/bsq code related to UI first and progressively removing/refactoring the underlying components while maintaining a working codebase.

[woodser]

Please keep in mind we want the minimum changes possible to remove the DAO.

[l0nelyc0w]

On Thu, May 20, 2021 4:57 pm, woodser wrote: Please keep in mind we want the minimum changes possible to remove the DAO.

After better understanding all the DAO I can refactor the code as needed and in any way you prefer. However as the DAO spans a lot of the codebase I need some advice as to which is the most preferable way to refactor some cases. Should the DAO folders be deleted or should all code be commented out? Should UI buttons that toggle between btc and bsq be removed or should their functionality be disabled? ``` An example: method(isBTC){ if (isBTC) { do btc stuff } else { do bsq stuff } }

…

------------------- current approach (A) (is this ok?) method(isBTC){ // l0nelyc0w: remove dao //if (isBTC){ do btc stuff //}else{ do bsq stuff } } ------------------- Another example: someClass{ someClass(btcwallet, bsqwallet, daoFacade){ this.bsqwallet = bsqwallet . . . someMethod( btcwallet, bsqwallet, daoFacade ) } } ------------------ initial approach (will be fully replaced by above (A)) someClass( someClass(btcwallet){ someMethod( btcwallet ) } } ------------------ ``` I can get accustomed to any styling you advise, just need some time to understand the codebase and your workflow. DAO is in a lot of codebase but I noticed that most of the time the refactoring problem belongs to four general cases to which the above are examples.

[premek]

I'm not someone who can decide anything here but I'd like to vote for NOT leaving commented code blocks in.

[l0nelyc0w]

@premek
@xrv0

I agree. Just wanted to make sure.

[woodser]

Yep agreed, let's remove the unused code blocks.

[erciccione]

Because of the current price drop and volatility, we decided to set the bounty for this issue in dollars: $250 (will be still released in XMR). The bounty was previously set at 0.6 Moneroj, which is about $127 at the current XMR price.

[l0nelyc0w]

It seems that I have underestimated the complexity of the dao issue. Removed some unit tests that I thought were relevant to dao, like offers with bsq as fee currency from non-guice tests. But I am currenly stuck at failing GuiceSetupTest for desktop and seednode and was't familiar with google's guice so I've been reading up on it to be able to debug it's error log. I get missing implementation errors that must be due to missing module installation within the injector.

[premek]

Not sure if it is feasible because of the bounty but if you push your WIP branch I can have a look. Not saying I'll be able to help but I can try :)

[l0nelyc0w]

@premek Feel free to check it out, I have pushed my commits on my branch: https://github.com/l0nelyc0w/haveno/tree/remove-dao. There must be a lot of mistakes, maybe I overdid it a little bit with code deletion, I feel that I am getting really close but at the same too many components and layers are involved and I've lost scope.

[erciccione]

Not sure if it is feasible because of the bounty

@premek the bounty can be split between multiple people, if they give a concrete contributions to solving the issue.

[erciccione]

We decided to raise the bounty to $400

[premek]

I just quickly skimmed through the changes and to me it looks like it's going in a good direction.

@woodser maybe you could give it 1 minute to see if it is in line with what you had in mind?
master...l0nelyc0w:remove-dao

@l0nelyc0w I checked out your branch, tried to compile and there was only one test failing that could be fixed if in BitcoinModule.java in configure() you do this instead of throwing the exception:
regTestHost = Config.DEFAULT_REGTEST_HOST;

Is there anything I can help with? Some isloated part that I can work on? Or something you had trouble with?

[l0nelyc0w]

@premek That did the trick, thank you very much! If you like you can help check if any of the removed unit tests should be refactored and reinserted (ex TxValidatorTest). An isolated part you can work on is GUI.

Currently (manually) testing desktop client and getting an error about MakerFee being zero during ValidateOffer when trying to create a new offer to sell XMR for BTC. I think @woodser said they are separate from security deposits and can be removed? What is the purpose of MakerFee (trade fee) and TxFee?

[woodser]

getting an error about MakerFee being zero during ValidateOffer when trying to create a new offer to sell XMR for BTC

The MakerFee is the maker's trade fee and I think the TxFee is the BTC fee estimate. There should be no functional change to these fields as part of DAO removal, even if removed in the future.

[woodser]

@woodser maybe you could give it 1 minute to see if it is in line with what you had in mind?
master...l0nelyc0w:remove-dao

I left some early general comments.

@l0nelyc0w, when ready, please squash commits to a branch for review.

[l0nelyc0w]

@l0nelyc0w when ready, please squash commits to a branch for review.

Will do, this was the WIP branch so commits were done mostly on a daily basis.

[premek]

@l0nelyc0w I made a PR from my fork into your fork with some more small removals, I hope we don't work on the same parts. I will try to continue when I find some time, so please push your changes when you make some. I will try to look at the GUI next time as you said

[erciccione]

Hey @l0nelyc0w @premek how is the removal going?

[l0nelyc0w]

@erciccione

Trying to debug some issues that have arisen during testing namely the following:
-when you try to create a new altcoin account thelist is empty in AltcoinAccountView (but in PreferencesView work ok)
-if you create an offer the buyer does not find the taker tx id
-blockchain does not confirm that the monero payment has been sent so trade cannot complete (but unlocks the coins sent from mining after some blocks)

These issues have been introduced after remove-dao changes, master branch works fine.
They slowed down my commits as I have yet to find how to correct the problem.

I have moved the project to a new workstation in order to create a dedicated environment but there are some problems related to the new setup like lombok version compatibility when debugging with codium that did not come up when building with ./gradlew build.

I will check out premek's PR today.
After the issues mentioned above are resolved, the final PR for the remove-dao issue will be available as soon as merging changes is complete.

[l0nelyc0w]

The last month since around the time the issue with transitive dependencies of jackson-annotations came up, I have been having some problems with gradle builds failing due to unresolved dependencies. Reasons are 403 Forbidden and connection time outs when trying to connect to repo.maven.apache.org and mvnrepository.com. As I am working from Whonix it seems that Cloudflare blocks requests from Tor exit nodes. This together with limited time this month has stalled any progress significantly as I could not build the project most of the time and I am considering getting a VPN to overcome this issue.

[erciccione]

Hey @l0nelyc0w how is this going? Any progresses?

[l0nelyc0w]

@erciccione

I decided to drop Whonix and setup a Debian 11 testing VM for developing haveno and I finally managed to build it a few days ago without any problems after a lot of frustration and failing builds.

I've resumed working daily on the issue and I am sure that it be fixed within this month.

Hope you can understand my frustration.
Will keep you updated.

[erciccione]

I understand, i just wanted to have the situation clear. Thanks for the update :)

Note that we implemented the new trade protocol with #107, so you probably want to rebase on top of that.

[woodser]

Please make sure you're working on the latest master which includes the new trade protocol.

[l0nelyc0w]

@erciccione
@woodser

I have rebased on top of upstream master, not many conflicts and most were easy to merge.
The problem I am currently facing is that when an open offer is taken by another party, it is marked as having an invalid state as soon as it is moved to open trades.
Maker's reason for invalid state is "The peer's taker fee transaction is missing."
The open trades state are also seen by the arbitrator as created by himself and can open chat window to send messages to the original creator of the offer.

[woodser]

The problem I am currently facing is that when an open offer is taken by another party, it is marked as having an invalid state as soon as it is moved to open trades.
Maker's reason for invalid state is "The peer's taker fee transaction is missing."

Did you recreate your application folders (seed, alice, bob, and arbitrator) after rebasing?

The open trades state are also seen by the arbitrator as created by himself and can open chat window to send messages to the original creator of the offer.

This behavior was the same before merging the trade protocol, I believe? It will need resolved as its own issue.

[l0nelyc0w]

Did you recreate your application folders (seed, alice, bob, and arbitrator) after rebasing?

Yes I removed the folders and started from scratch.

This behavior was the same before merging the trade protocol, I believe? It will need resolved as its own issue.

Yes this behavior was the same before merging.

Neither problem is related to the new or the old trade protocol, they have to do with changes on my branch.
I think if I resolve those two issues, the branch will be ready for merging with upstream.

[woodser]

it is marked as having an invalid state as soon as it is moved to open trades

Where do you see it marked as invalid state?

[l0nelyc0w]

Where do you see it marked as invalid state?

In the open trades window it is marked on the left side of the view next to its id and on the right side of the view next to the chat icon.

[woodser]

Got it. These errors are false alarms. They reflect outdated checks and legacy gui which expect a separate fee transaction.

Opened an issue to remove these false errors: #113

[l0nelyc0w]

Got it. These errors are false alarms. They reflect outdated checks and legacy gui which expect a separate fee transaction.
Opened an issue to remove these false errors: #113

Ok will try to find out why the open trades are also accessible from the arbitrator.
Will keep you updated.

[woodser]

Unless your branch introduces issues not present on master, fixing the arbitrator trade step view should be done as a separate issue and PR.

Currently when an arbitrator starts arbitrating a trade, it creates an internal trade which then appears under its Open Trades. Perhaps such trades should be completely hidden from Open Trades, or that view could be updated to correctly show the arbitrator progress.

[l0nelyc0w]

Unless your branch introduces issues not present on master, fixing the arbitrator trade step view should be done as a separate issue and PR.

Will build latest master to check out latest behavior.

Currently when an arbitrator starts arbitrating a trade, it creates an internal trade which then appears under its Open Trades.

Noticed the role the arbitrator plays during the multisig but wasn't aware of the visibility of that trade on the UI.

I will check if any other issues exist solely on my branch and the existence of any behavioral deviations from master and will update you accordingly.

[l0nelyc0w]

So after building upstream master I can confirm that both the arbitrator's view and invalid trade false flag existed on upstream before merging.

I have successfully completed both a BTC/XMR and XMR/BTC trade on my local branch after rebasing on upstream with new trade protocol. If anyone can test it to confirm that building and using my branch produces the same behavior with upstream it would be very helpful.

No dependency on, or functionality of DAO is left.
I can remove any remaining references to unused resources and methods related to DAO and BSQ and review for merging with upstream.

[l0nelyc0w]

Removed most references left relevant to dao, apart from strings in i18n.
I think it works fine, completed about 20 trades while continuously building and testing.
Will rebase again on upstream master and then will be ready for PR.

[l0nelyc0w]

Rebased and resolved conflicts.
Preparing for PR.

[erciccione]

Patch proposed: #121

[erciccione]

We decided to raise this bounty to $600. Contributors that are contributing to solve this issue will also receive a reward.

[erciccione]

@l0nelyc0w @premek #121 has been merged. Please give us a Monero address where we can send the bounty :) (a pm on matrix will be ok if you prefer to not share it publicly).

[erciccione]

$600 (2.24 XMR) were sent to @l0nelyc0w. A token of appreciation was also sent to @premek for their help. Please confirm you received the rewards.

[premek]

A token of appreciation was also sent to @premek for their help. Please confirm you received the rewards.

Received, thanks a lot

[l0nelyc0w]

Please confirm you received the rewards.

I confirm I received the reward. Thank you very much.

[erciccione]

Thanks everybody :)