Refactor dao monitor handling #5780
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…core.offer.placeoffer.bisq_v1
BuyerAsMakerTrade, BuyerAsTakerTrade, BuyerTrade to bisq.core.trade.model.bisq_v1 package
Move TradeMessage into bisq.core.trade.protocol package
…ore.trade.bisq_v1
…radeUtil, TradeTxException to package bisq.core.trade.bisq_v1
We create a new address entry when opening the create offer view. But we close and replace that view with the BSQ swap create offer view if BSQ swap is selected, therefore the address entry would be dangling and later cleaned up at openOfferManager. To clean it up directly we call the resetAddressEntriesForOpenOffer on btcWalletService.
in signBsqSwapTransaction. Remove unused code
Extract variables, inline method
Let DaoStateSnapshotService do the coordinated call of `daoStateMonitoringService.createHashFromBlock(block);` and then `maybeCreateSnapshot(block);`
if `preferences.isUseDaoMonitor()` is true
but activate it later so they have a gap in the chain) we set a flag instead throwing an error and inform listeners. UI will react on that and suggest a resync.
Add popup if re-activate
We use default value false but seeds should have default value true.
super class to concrete class. Handle text and button visibility in DaoStateMonitorView.
We used prevHash only for display in the UI but it did not had any functional usage. It took about 50% of the data size of the StateHashes (about 3 MB out of 6 MB total storage size). The prevHash is used only as part of the pre image for the hash but we take the hash of the previous StateHash item and then stored that in the newly created StateHash item. So we do not change that the previous item is part of the new hash, but only that we do not persist it as it is not required and helps reduce the data load.
DaoStateBlock) so that we can persist it. Apply the dao state hashes received from the seed nodes to our chain.
chimp1984
changed the title
|
Will re-open PR once complete. Had got too many changes.... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on #5775
Starts at: 1ef21ac
Fixes #5779
This adds a flag to preferences for useDaoMonitor which is false by default.
Users can activate DAO state monitoring in the DAO monitor view or settings.
The Monitoring for proposal and blind vote data is not changed by that PR.
The hash creation for DAO state monitoring is due the large data set pretty slow. This makes a DAO sync for 1 months of data to take about 10-15 min. Without that hash creation for DAO state monitoring the DAO block parsing takes only 4 sec. for the same amount of blocks.
Power users should still keep it activated. But I think for most users its a unacceptable experience.
I will look further into a larger DAO state refactoring and maybe I find a new way how we can provide the feature without that high costs.