Someone explain to me how this voting works, is it random or what?
i.e. what's to stop me from setting up my own masternode and voting for it in all the blocks Multipool finds, or selling my votes to someone?
i.e. what's to stop me from setting up my own masternode and voting for it in all the blocks Multipool finds, or selling my votes to someone?
Question : https://darkcointalk.org/threads/help-test-rc2-forking-issues.1009/page-12#post-6973
Evan's answer : https://darkcointalk.org/threads/help-test-rc2-forking-issues.1009/page-13#post-7060
Quote
Thanks for the super detailed report. So what you posted actually looks fine. I'll try to explain what's happening.
Block 14217
If you mined this block, your client added the pubkey for 14217.
It's also allowed to increment each existing vote by one if it agrees with it. So the code goes something like this:
On block 14214 was the pubkey to be paid fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o?
If yes increment votes from 1 to 2
If no and votes=1, change pubkey to the correct one and don't vote (this only can happen get no voting has happening and it looks incorrect)
On block 14215 was the pubkey to be paid nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE?
If yes increment votes from 2 to 3
If no, don't vote
On block 14216 was the pubkey to be paid QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk? If yes increment votes from 1 to 2
Added block 14217, pubkey Z92SLSwb3z2D47g47Y1E9LczimJiVFtvv, votes 1
Block 14217
Code:
Blockheight Pubkey Votes
14214 fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o 2
14215 nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE 3
14216 QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk 2
14217 Z92SLSwb3z2D47g47Y1E9LczimJiVFtvv 1
14214 fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o 2
14215 nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE 3
14216 QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk 2
14217 Z92SLSwb3z2D47g47Y1E9LczimJiVFtvv 1
If you mined this block, your client added the pubkey for 14217.
It's also allowed to increment each existing vote by one if it agrees with it. So the code goes something like this:
On block 14214 was the pubkey to be paid fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o?
If yes increment votes from 1 to 2
If no and votes=1, change pubkey to the correct one and don't vote (this only can happen get no voting has happening and it looks incorrect)
On block 14215 was the pubkey to be paid nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE?
If yes increment votes from 2 to 3
If no, don't vote
On block 14216 was the pubkey to be paid QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk? If yes increment votes from 1 to 2
Added block 14217, pubkey Z92SLSwb3z2D47g47Y1E9LczimJiVFtvv, votes 1
Thanks but this doesn't explain where the pubkey to add is coming from.
pubkey of payee ?
It's on getblocktemplate
https://github.com/darkcoinproject/darkcoin/blob/master/src/rpcmining.cpp#L572-L581
Code:
ExtractDestination(pblock->payee, address1);
https://darkcointalk.org/threads/help-test-rc2-forking-issues.1009/page-13#post-7066
Quote
Hi Evan,
thanks for the explanation, i think i got it. The problem was not the algorithm,
but my idea how the voting actually works in P2P networks - i guess i should have read the fucking manual :grin:
So this is my understanding now:
- A certain block is found by a miner
- The miner is looking up the previous block from the blockchain to get the current vote list
- Its appending the pubkey of a MN winner - the actual vote
- Additionally the miner is checking all previous vote pubkeys and if it agrees with it adding another vote - lets call it 'confirm vote'
- If the miner does not agree it replaces the pubkey with a new one. Its the job of the next miner to agree or disagree with that
So what basically confused me was the term 'vote'. My idea was that each miner is only giving ONE vote,
but not confirming the others. That also explains why my math on the expected payout was wrong: I expected that only 1/6th of blocks get paid.
But with the vote confirmations it makes sense again: That way each block will be paid out in the future.
And the scheme we are seeing on the explorer now is expression that the system is working as designed
thanks for the explanation, i think i got it. The problem was not the algorithm,
but my idea how the voting actually works in P2P networks - i guess i should have read the fucking manual :grin:
So this is my understanding now:
- A certain block is found by a miner
- The miner is looking up the previous block from the blockchain to get the current vote list
- Its appending the pubkey of a MN winner - the actual vote
- Additionally the miner is checking all previous vote pubkeys and if it agrees with it adding another vote - lets call it 'confirm vote'
- If the miner does not agree it replaces the pubkey with a new one. Its the job of the next miner to agree or disagree with that
So what basically confused me was the term 'vote'. My idea was that each miner is only giving ONE vote,
but not confirming the others. That also explains why my math on the expected payout was wrong: I expected that only 1/6th of blocks get paid.
But with the vote confirmations it makes sense again: That way each block will be paid out in the future.
And the scheme we are seeing on the explorer now is expression that the system is working as designed
