-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Remove all legacy pre-DIP3 masternode and compatibility code #2566
Conversation
There are still places where these are used in the code. The next commits will clean these up.
Also replace all uses of IsMasternodeListSynced and IsWinnersListSynced with IsBlockchainSynced.
And only leave the code paths that would be executed when the spork is active (which it implicitely is with the next release). Also remove all methods that do nothing with the spork active.
…ministicMNManager
And remove them with direct use of deterministicMNManager
…e used directly Additionally, implement GetLastDsq in CMasternodeMan as a replacement for direct access to the masternode_info_t object. Will move this variable to another (PS specific) place later.
And adapt it to directly use deterministicMNManager
…kTxOuts ...and let it crash instead. We expect this method to be called with the correct height now (after DIP3 was fully deployed).
And always enforce payments.
…PAY_UPDATED_NODES
Only masternodes sign governance objects, so there is no need for ECDSA support here anymore.
IsDIP3Active will now use a fixed parameter from consensus params. Values for DIP0003Height/DIP0003Hash need to be updated when spork15 activates on testnet/mainnet. Also enforce correct block hash on mainnet for DIP3 activation block.
Also delete guide-startmany.md and masternode_conf.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noticed few things, see below.
strUsage += HelpMessageOpt("-mnconf=<file>", strprintf(_("Specify masternode configuration file (default: %s)"), "masternode.conf")); | ||
strUsage += HelpMessageOpt("-mnconflock=<n>", strprintf(_("Lock masternodes from masternode configuration file (default: %u)"), 1)); | ||
strUsage += HelpMessageOpt("-masternodeprivkey=<n>", _("Set the masternode private key")); | ||
strUsage += HelpMessageOpt("-masternodeblsprivkey=<n>", _("Set the masternode BLS private key")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This help message should be added in 0.13 actually
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see #2569
@@ -2036,29 +1998,18 @@ bool AppInitMain(boost::thread_group& threadGroup, CScheduler& scheduler) | |||
|
|||
strDBName = "mncache.dat"; | |||
uiInterface.InitMessage(_("Loading masternode cache...")); | |||
CFlatDB<CMasternodeMan> flatdb1(strDBName, "magicMasternodeCache"); | |||
if(!flatdb1.Load(mnodeman)) { | |||
CFlatDB<CMasternodeMetaMan> flatdb1(strDBName, "magicMasternodeMetaCache"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is altering magic necessary? This will require user to manually delete the file on wallet upgrade which could be annoying. Altering "version" should already do the job and clear all the previous data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah didn't notice the extra handling of the magic string and assumed it's only the string compare in the serialization methods. Will change this later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, the purpose of the magic string is to ensure that this is exactly the kind of file we expected and not some renamed wallet.dat for example (in which case user will have to manage things manually and rename it to smth else).
Misbehaving(pfrom->GetId(), 100); | ||
return; | ||
} | ||
if (!spork.GetSignerKeyID(keyIDSigner) || !setSporkPubKeyIDs.count(keyIDSigner)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can only be done after spork6 is activated on mainnet (it's still OFF atm). I would not include these changes (and similar) in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, will remove these changes
Hey @codablock , this is a great effort. Glad to see us start removing the old legacy code.
I like that you're removing all this old stuff, but I don't agree with your rationale for the really big PR. For example, you can remove protocol documentation in a later PR and keep the code PR minimal. Or another example (and I've only glanced at this for now), some of the string / RPC usage cleanup is just general "cleanup" and not specific to removing old MN logic, but it gets too easy to stuff simple things in here and this becomes too large and generic. As you know, I'm very skeptical of overly large PRs because they inevitably introduce bugs which are harder to catch due to the size of the diff. And that's of course the reason that is in our PR guidelines as well:
I wanna remove this old stuff as much as you do, and I do understand it's all connected once you dive down this rabbit hole, but in general I think we should be able start sticking closer to these guidelines and make these smaller. Here are some ideas for separate PRs:
Here are 2 more which are probably related and harder to tease apart, so these might be fine together (would still prefer if possible to separate them):
Of course those are just your own bullet points, split up. I'm going to try a full review of this (again, this becomes harder the larger these get), but this first one I think should esp. be separate, otherwise we mix refactoring, cleanup, new features, documentation, all in one massive PR. I hope you understand and can agree with this, but please let me know your thoughts. |
@nmarley Thanks for your review and notes. I will work on splitting this further up after the v13 release, until then it's probably better to wait with deeper reviews. |
Sounds good, thanks @codablock |
closing this now as I started doing smaller PRs |
This PR is meant for v14 and will not be merged into v13. This should be one of the first things we takle when starting development on v14.
It does the following:
CMasternodeMan
to directly useCDeterministicMNManager
.CMasternodeMetaMan
as a replacement for the things that would have stayed in CMasternodeMan. The idea behind it is to store meta-information (e.g. about mixing and governance) that is not derived from on-chain data.SPORK_6_NEW_SIGS
and all the logic for it)This PR got quite huge and I'm not sure if I'll be able to extract portions of it into smaller PRs. The problem here is that touching a single place very often breaks everything, requiring to fix more and more until you're back to very huge PR.
In the current state, tests will very likely fail. I'll start fixing them later when work on v14 actually starts.