-
Notifications
You must be signed in to change notification settings - Fork 717
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
[Masternodes] dead end over the activation process. #1886
Conversation
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.
Awesome catch. 🍻
Concept ACK. Only minor thing, I suggest a name change for the new function.
A valid masternode is created, mn start message is broadcasted and the entire network receives it. Peers move the masternode status to pre_enable (active) and are waiting for a mn ping update to fulfill the min ping time requirement after it activation to move to enable. Issue: As the mnping update message work flow is not performing any action until the masternode is in enable status (masternode.cpp, line 707), the masternode ping is never updated, there by the masternode will never be moved to enable status.
abb8bef
to
2e3e313
Compare
Updated per feedback. |
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.
tested ACK 2e3e313
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.
utACK 2e3e313
Solving a dead end inconsistency over the masternode activation process.
Context:
A valid masternode is created, mn start message is broadcasted and the entire network receives it. Peers moves the masternode status to pre_enable (active) and are waiting for a mn ping update to fulfill the min ping time requirement to move the status to enable.
Issue:
As the mnping update message work flow is not performing any action until the masternode is in an enable status (masternode.cpp, line 707), the masternode ping is never updated, there by the masternode will never be moved to enable status.
Why this is working now:
It's working because (1) the masternodes list is being requested, cleaned and re requested an insane amount of times, (2) some peers are broadcasting the start message twice and (3) peers are broadcasting a start message with an inner ping time in the future, fulfilling the min ping requirements.
Final thoughts:
This is most likely one of the reason of the different masternodes list views across peers in the network (over the recently active/enable MNs) and why the activation process takes in some occasions few days (the mn list needs to be refreshed)
Extra data:
The masternodes list request + re-request network bloat, as is mentioned in point 1 of the "Why is working now" section, will not happen anymore in the future moving forward with Tier two network sync new architecture, regtest support + MN activation functional test. #1829 new tier two syncing process subsequent steps, the deterministic masternodes implementation and all of the PRs refactoring & cleaning the tier two sources (in other words, after the whole tier two sources revamp..).
This PR makes Tier two network sync new architecture, regtest support + MN activation functional test. #1829 4963953 hack unneeded.