V0.12.0.x use specific proto and fix sync issues #441
Conversation
|
Don't merge it yet, having issues syncing during forks |
| //don't begin syncing until we're at a recent block | ||
| if(pindexPrev->nTime + 600 < GetTime()) return; | ||
| //don't begin syncing until we're almost at a recent block | ||
| if(pindexPrev->nHeight + 4 < pindexBestHeader->nHeight || pindexPrev->nTime + 600 < GetTime()) return; |
There was a problem hiding this comment.
Shouldn't we wait to ask for mnb/mbp until we have the most recent block? Otherwise if a masternodes input is newer than the current block, we will reject it and have inconsistancies
There was a problem hiding this comment.
Well, I agree. I'm not sure on that either tbh. I just divided 600 by blocktime (i.e. 150) and that's where 4 came from :)
On another note we are just entering cycle to ask other nodes for MNs so most likely we'll be already at a recent block when the first mnb from them arrive.
There was a problem hiding this comment.
Gotcha, shouldn't it be "pindexPrev->nHeight + 4 > pindexBestHeader->nHeight" though? Being that we get the headers first and we're checking to see when the chain actually downloads, right?
There was a problem hiding this comment.
err... nope. Say we have 100 headers and only 10 blocks so
if (10 + 4 < 100 || ...) return; // do not sync yet
Or am I missing smth?
I would agree however that it's better to use && here
if(pindexPrev->nHeight + 4 < pindexBestHeader->nHeight && pindexPrev->nTime + 600 < GetTime()) return;
i.e. if block height is still low AND block time is low too THEN do nothing. Thoughts?
There was a problem hiding this comment.
Oh, I just was reading it backwards somehow :) I think using && is probably
a lot better in that case
On Sun, Jul 19, 2015 at 7:46 AM, UdjinM6 notifications@github.com wrote:
In src/masternode-sync.cpp
#441 (comment):
//don't begin syncing until we're at a recent blockif(pindexPrev->nTime + 600 < GetTime()) return;//don't begin syncing until we're almost at a recent blockif(pindexPrev->nHeight + 4 < pindexBestHeader->nHeight || pindexPrev->nTime + 600 < GetTime()) return;err... nope. Say we have 100 headers and only 10 blocks so
if (10 + 4 < 100 || ...) return; // do not sync yet
Or am I missing smth?
I would agree however that it's better to use && here
if(pindexPrev->nHeight + 4 < pindexBestHeader->nHeight &&
pindexPrev->nTime + 600 < GetTime()) return;
i.e. if block height is still low AND block time is low too THEN do
nothing. Thoughts?—
Reply to this email directly or view it on GitHub
https://github.com/dashpay/dash/pull/441/files#r34958712.
There was a problem hiding this comment.
yeah, np, happens to me too sometimes 😄
changed to &&, see next commit
|
rebased |
…ments.GetMinMasternodePaymentsProto()
|
Ok, rebased again and also removed |
V0.12.0.x use specific proto and fix sync issues
…igner 2efdfb8 gui: restore Send for external signer (Sjors Provoost) 4b5a6cd refactor: helper function signWithExternalSigner() (Sjors Provoost) 026b5b4 move-only: helper function to present PSBT (Sjors Provoost) Pull request description: Fixes dashpay#551 For the simplest use case of a wallet with one external signer and "PSBT Controls" disabled in settings (the default), the send dialog will behave the same as when using a wallet with private keys. I.e. there's no "Create Unsigned" button. When PSBT controls are turned on, you can now actually make a PSBT with signing it; before this PR that button would trigger a sign event and would broadcast the transaction. In case a multisig, the Send button will sign on the device, and then fall back to presenting a PSBT (same behavior as before dashpay#441). This PR starts with two refactoring commits to move some stuff into a helper function for improved readability in general, and to make the main commit easier to review. ACKs for top commit: jonatack: utACK 2efdfb8 diff review since my last review, code re-review, rebased to current master, verified clean debug build of each commit luke-jr: utACK 2efdfb8 Tree-SHA512: e8731a0ef9e87564b2676c7b022b742d9621bba964c19dba9fd9f6961eb608737a9e1a22c0a3c8b2f2f6d583bba067606ee8392422e82082deefb20ea7b88c7c
use<--- doesn't play nice with forkspindexBestHeaderheight to identify recent block instead of magic timelast...on sync initial statelastMasternodeListwhen we received legit update for MN we already knowmnbonmnpeven if not synced yetcount