…chronization state.

if it happens before or while the node's tier two initial synchronization is being executed, the peer will move to single items requests instead of requesting the full list.

Plus, decrease the DoS score for a bad mnb signature during the initial synchronization process, so we don't end up banning pre v5.3.3 nodes too fast for an invalidly serialized mnb (this issue was solved in bitcoin#2611 removing the mnb BIP155 flag, this is only an extra guard to give a bit more time to non-updated peers to upgrade while the network is upgrading).

…chronization state.

if it happens before or while the node's tier two initial synchronization is being executed, the peer will move to single items requests instead of requesting the full list.

Plus, decrease the DoS score for a bad mnb signature during the initial synchronization process, so we don't end up banning pre v5.3.3 nodes too fast for an invalidly serialized mnb (this issue was solved in bitcoin#2611 removing the mnb BIP155 flag, this is only an extra guard to give a bit more time to non-updated peers to upgrade while the network is upgrading).

…in initial sync state

860fa5a TierTwo: do not ask for single MN items if the node is in initial synchronization state. (furszy)

Pull request description:

  Solving a last edge case race condition for the tier two initial sync process:
   if a `fbvote` or `fbs` message is received before or while we are synchronizing the MN list, there can be a race where the node will move to single items requests instead of requesting the full list (which is not what we want in the initial sync process as single items requests sync is a reactive approach while full list requests is a proactive one).

  Plus, decreased the DoS score for a bad mnb signature during the initial synchronization process, so we don't end up banning pre v5.3.3 nodes too fast for an invalidly serialized mnb (this issue was solved in #2611 removing the mnb BIP155 flag, this is only an extra guard to give a bit more time to non-updated peers to upgrade while the network is upgrading).

ACKs for top commit:
  Fuzzbawls:
    ACK 860fa5a
  random-zebra:
    utACK 860fa5a

Tree-SHA512: b490adddd4cf229f0a20a59b4d8402dd87b9dcbba8cfa32994d2e9dfdecb3c120f6decca22d03d91ab6892c733b954c35e0a114d27784e15863b6c740353339b

e43a239 TierTwo: do not ask for single MN items if the node is in initial synchronization state. (furszy)
1a3f7e0 [GUI] Force argument insertion when switching languages (Fuzzbawls)
9ea042c refactor: rename DsegUpdate to RequestMnList (furszy)
60767c0 TierTwo: when the INV is received, remove it from every peer AskFor set. (furszy)
6ece735 net: do not relay INV messages to not successfully connected peers. (furszy)
ff181f1 TierTwo: Only relay data if we aren't on the initial synchronization phase. (furszy)
bf5f78e net_processing: improve INV processing for tier two elements. (furszy)
a5ff7f8 Masternode: clean possible invalidly stored seen MN broadcasts at startup. (furszy)
e024421 Masternode: remove own mnb validation skip. (furszy)
3dec0cd Masternode-sync: Count local MN, in case of have it, for fallback sync issue. (furszy)
a729fc9 Masternode: pre-v6.0 guard against an invalidly stored BIP155 masternode addr that causes a signature verification failure. (furszy)
66568c6 Masternode: remove error-prone 'isBIP155Addr' flag, use directly the addr isCompat function. (furszy)
df1b3cc test, governance sync: increase tier two network gossip movement (furszy)
15f5a70 test: add tier two resync from scratch test case. (furszy)
ee7cc08 TierTwo sync: raise mn list sync time to 40 seconds. (furszy)
2240602 net bugfix: clear waiting for response INVs from the "askedFor" set when the item is received. (furszy)
5dd052c tier two: do not request single missing mn entries until the initial sync process is completed. (furszy)
156b6a9 MasternodeMan: remove mainnet only check for the "already asked mn list sync" DoS validation. (furszy)
be5bf14 Raise max mnlist sync threshold, increase budget sync finish timeout and document masternode-sync process. (furszy)
c1c1044 Bump protocol version to 70924. (furszy)
09c72c5 budget sync: if budget finalization fails, not only request missing proposals, request proposals' votes as well. (furszy)
0726c16 budget sync: do not block budget full sync requests forever. (furszy)
95bbbd5 mnsync: randomize the sync requests order so the node try to sync from different peers in case of needing it. (furszy)
bbb28fe mnsync: do not mark get_mn_list peer sync fulfilled if the request wasn't done. (furszy)
6d285b2 Test: add test case for budget data re-synchronization. (furszy)
2bde6fc [RPC] Add cleanbudget command. (furszy)

Pull request description:

  Backports #2611 for v5.3.3

  So we do a release focused on solving tier two network synchronization and re-synchronization issues that are mainly affecting the superblock payments window and causing network forks.

  Update:
  Added #2617 and #2622 as well.

ACKs for top commit:
  random-zebra:
    utACK e43a239 then
  Fuzzbawls:
    ACK e43a239

Tree-SHA512: ea7e1730caaefc48a49edd7610bd9874fdcbabd6365a818313f3b418eb77fd95b0bdeb32bacdfdeefee8dddb3edc422ebaa2e85a1c93df51ee66fc64f40a68bb

…allet_nullifiers

0f79bdc [QA] Fix intermittent mempool sync failures in sapling_wallet_nullifiers (random-zebra)

Pull request description:

  Still (somewhat frequent) mempool sync failures in this test, even after #2633.

  This is because `node1` might still be in IBD when he receives the first tx INV message, and, with #2611, nodes no longer send (non-block) getdata requests during initial sync.

ACKs for top commit:
  furszy:
    great catch, ACK 0f79bdc.
  Fuzzbawls:
    ACK 0f79bdc

Tree-SHA512: a3f3b81848893803ba04e93d605d7d6accb2b2a28c62a8d7dbd09ae5513111c917c46f1e30eccacdf9b6ac9f1caf06ff4383fd0071d55133f49e8798e68933d4

…set.

9b5fd1c test: remove duplicated and non-existent CInv types. (furszy)
96c64ec test: add case for full askfor set. (furszy)
d495d27 Clean seen MN pings map right after the MN is removed. (furszy)

Pull request description:

  Follow-up work to #2611.
  Adding a regression test case for one of the issues solved in #2611:

  As none of the mnp inv requests were being removed from the waiting for response inv set and map when the item arrives.
  The set was growing non-stop for the entire node life cycle up to the point where no subsequent inv msg were accepted anymore.

  After v6.0, as the mnp message will be removed, the test can be moved to be based on quorum inv msgs.

ACKs for top commit:
  random-zebra:
    ACK 9b5fd1c
  Fuzzbawls:
    ACK 9b5fd1c

Tree-SHA512: 8b8a54edc30bba9b81cd375b478356c929e8a6868d09ce7af9dccfe7a1289436786a970dd55a05ea75ff7d022cbfee4a70706adf0cb10a9d72421a66202998ef