Thanks for your reply!Last Paid (from dashd) is the information retrieved from dashd and from blocks is directly from blocks information by Dash Ninja.
Sometimes they are not agreeing and the background is red. Nothing important as long as you get paid.
Missed payment means there was no payment in the block where your masternode was expected to be paid.
Hijacked means the reward was payed to another masternode but yours was elected in the block template.
Thanks, UdjinM6.@dark_wanderer If it was 10 days already then dashd (12.0) could see it as "never paid" even if it was before but that's ok, it means that you are in top 10% from which MNs are picked randomly so just keep your mn online do NOT restart it via masternode start-* commands and it should be paid eventually. If you restart, it will be brought to the end of the queue and you'll have to wait 7+ days to get into that top 10% again.
No, the "luck" is "how close am I to some random-ish (but deterministic) hash?" and you can't predict that future hashThanks, UdjinM6.
As a follow up on the randomness of the selection: if a masternode was "unlucky" in the last round, does that mean that it will be "luckier" in future rounds so that on average each masternode has the same expected payment?
no, static IP is only required to make it discoverable/availableBut if you dynamiccaly change IPs, is it equivalant to restarting ?
masternodeman.cpp, look for `CMasternodeMan::GetNextMasternodeInQueueForPayment` and dig from thereSorry for off-topic here, but could you please post the name of the source file with the implementation of this random/deterministic selection?
I still have to code the front-end for the new system.In the old budget system we could see the masternodes who voted. For example: the old 10-Video-Tutorials proposal. https://www.dashninja.pl/budgetdetails.html?budgetid=10-Video-Tutorials . All masternodes' votes are visible.
The votes are there in Dash Ninja database and you can also retrieve them using dashd or the Dash Core debug console.
I am not accessing Sentinel db at all, yet (maybe it will be needed for Evo). Everything I need is in dashd and can be retrieved via RPC calls.
Aha! Instead of asking the database directly, you are quering the votes from the dashd via rpc calls, and dashd asks sentinel's python, and python asks sqlite database, and the sqlite database is written into the disk drive directly as a file, and the disk is a network disk and it swaps awfully, and the sockets timeout, and the dashd threads timeout and a lock occurs! I think I discovered the reason of the sync problems!I am not accessing Sentinel db at all, yet (maybe it will be needed for Evo). Everything I need is in dashd and can be retrieved via RPC calls.
You dont need to have sentinel on you desktop, as long as you read the debug console, or as long as you use rpc calls.100% sure, I have no Sentinel on my desktop but I can retrieve them from the debug console of my dash-qt.
Thanks for the easy dash...
I read the code.
The votes are not in Sentinel, they are part of gobjects in Dashd.
Anyway, thanks both of you for your remarks.
The country is retrieved using geoip database from the IP of your masternode.
In my case, dashninja geoip database not going good, I have check IP and is visible as US but I checked and have IP from ShanghaiThe country is retrieved using geoip database from the IP of your masternode.
So if it was not set by your hosting provider, it will be unknown.