[Masternodes] dead end over the activation process. #1886
Merged
Conversation
This file contains hidden or 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
random-zebra
reviewed
Oct 3, 2020
random-zebra
left a comment
random-zebra
left a comment
There was a problem hiding this comment.
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.
furszy
force-pushed
the
2020_mn_ping_update
branch
from
abb8bef to
2e3e313
Compare
Author
|
Updated per feedback. |
furszy
changed the title
furszy
changed the title
Fuzzbawls
approved these changes
Oct 8, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
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.