- Syncing process is now event based, rather than timeout based. This means the system can tell when it's done with each step and moves on between phases much faster. In initial testing it seems to be about 10-15x faster and has synced everytime successfully.
- Please remove print debugging when the syncing system is proven to be debugged.
- lower MASTERNODE_SYNC_THRESHOLD (4->2)
- higher wait MASTERNODE_SYNC_TIMEOUT*2 and fail MASTERNODE_SYNC_TIMEOUT*5 timeouts for each step
- ask at most MASTERNODE_SYNC_THRESHOLD*3 nodes for sync data
- sync again 1 minute after last fail
So we will ask at most 6 nodes and stop updating lastTime...s when we had data from at least 2 of them but will fail if we had nothing in 25 sec since current step start.
In case of fail resync again faster.
- use map.insert instead of [] (should be safer)
- debug output / comments / spaces / names
- fix few long strings / make translatable one more label in UI
- Budgets now store the seen objects locally so they're not overwritten when saving/loading to check validity of budget.dat
- Added safer sync "failure" mode, that will retry an hour later if the sync fails for some reason. This will stop the client from thinking it has budget data and rejecting blocks when they're valid.
- protocol bump
- version bump
- if(pindexPrev->nHeight + 4 < pindexBestHeader->nHeight || pindexPrev->nTime + 600 < GetTime()) return;
-- && allowed skipping in various situations, which caused blocks to be rejected because of lack of mnfinalbudget data
- Use INV messages where possible in syncing process
- Ask 4 peers intend of 2 to send of inventory of mnw, and budgets
- Special regtest sync mode
- Fix mnw freezing issue (maybe)
- Consensus system selects 1/10 of the oldest masternodes by payment, then selects payee by score from those. This fixes various race conditions when blocks are close together or inconsistant historical winner lists.
- Ask for up to 2 cycles of history
- Keep up to 5 cycles of history locally
- Cache saves masternode payment history
- On startup, the client will find the most recent block and calculate the amount of entries to ask for. The other peer will then send that amount of entries to save bandwidth on restarts.
