[budget] partially fixing a race condition that could cause a good peer to be banned #2395
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.
Moved
TRY_LOCKtoLOCKto perform the budget maps check every 14 blocks without exception. If peers doesn't perform the validation and update proposals, votes and budget finalization maps at a similar network time, there could be a peer sending votes that aren't longer valid and end up being banned.This is just an initial small mitigation, have seen peers banning other peers for this race condition. This area needs a further rework later on.
Budget data is being validated on every new arriving block while the masternodes status is being checked and updated every 5 seconds (which is way too fast and not needed but that is another topic). The budget data update should be done right after the masternode removal/invalidation, so the peer updates the budget maps and does not send the invalid data to the network (important note: better to do this rather than force a budget data check and update on every peer sync request).
Plus will probably work in another PR in decoupling the called "masternodeds thread" into its proper file and update budget data from it as well (solving some cyclic dependencies in the way).
-- This is something to have in mind for DMN and the future PoSe too. The budget maps check and update should be done right after the masternode removal/invalidation and not at different times --