• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

v0.10.9.x Help test RC2 forking issues

Status
Not open for further replies.
my list after several hours

My current list with 62 active MNs - started with 1..2..3..4 (see one my previous posts) - and suddenly jumped to 55+ after 1h, very much like the graph on http://tdrk.poolhash.org/

Code:
testnet3@ip-10-65-166-48:~/.darkcoin$ ./darkcoind masternode list | grep 19999 | sort -V
    "23.20.78.184:19999" : 1,
    "23.22.13.31:19999" : 1,
    "23.23.55.5:19999" : 1,
    "50.16.10.185:19999" : 1,
    "50.16.13.19:19999" : 1,
    "50.16.50.164:19999" : 1,
    "50.16.159.173:19999" : 1,
    "50.17.9.225:19999" : 1,
    "50.17.56.71:19999" : 1,
    "50.17.76.216:19999" : 1,
    "50.19.54.118:19999" : 1,
    "54.80.118.25:19999" : 1,
    "54.80.186.130:19999" : 1,
    "54.80.217.163:19999" : 1,
    "54.80.221.149:19999" : 1,
    "54.80.248.174:19999" : 1,
    "54.81.150.16:19999" : 1,
    "54.81.244.239:19999" : 1,
    "54.82.237.183:19999" : 1,
    "54.83.143.1:19999" : 1,
    "54.83.151.118:19999" : 1,
    "54.86.103.191:19999" : 1,
    "54.87.101.82:19999" : 1,
    "54.87.121.203:19999" : 1,
    "54.187.152.9:19999" : 1,
    "54.197.189.67:19999" : 1,
    "54.197.213.80:19999" : 1,
    "54.198.109.108:19999" : 1,
    "54.198.145.174:19999" : 1,
    "54.198.191.99:19999" : 1,
    "54.198.252.150:19999" : 1,
    "54.209.226.236:19999" : 1,
    "54.211.202.218:19999" : 1,
    "54.224.28.113:19999" : 1,
    "54.224.75.195:19999" : 1,
    "54.224.75.199:19999" : 1,
    "54.225.6.1:19999" : 1,
    "54.226.159.60:19999" : 1,
    "54.227.104.145:19999" : 1,
    "54.227.119.61:19999" : 1,
    "54.234.251.170:19999" : 1,
    "54.237.191.208:19999" : 1,
    "54.242.110.149:19999" : 1,
    "54.242.139.236:19999" : 1,
    "54.242.152.165:19999" : 1,
    "87.230.94.57:19999" : 1
    "107.20.4.185:19999" : 1,
    "107.20.28.12:19999" : 1,
    "107.20.38.255:19999" : 1,
    "107.20.122.204:19999" : 1,
    "107.21.138.152:19999" : 1,
    "107.22.42.148:19999" : 1,
    "108.61.199.47:19999" : 1,
    "184.73.34.180:19999" : 1,
    "184.73.48.127:19999" : 1,
    "184.73.114.32:19999" : 1,
    "184.73.179.148:19999" : 1,
    "184.73.179.187:19999" : 1,
    "184.73.179.196:19999" : 1,
    "188.226.133.22:19999" : 1,
    "188.226.248.36:19999" : 1,
    "204.236.211.102:19999" : 1,
 
Last edited by a moderator:
Hi Evan,

good work, works much better for me so far. Nevertheless i have found something which either is a bug in the abe blockexplorer or in the algorithm how the clients store the votes in the blockchain.

If you look at the blocks 14214+ since the payout started you will notice the following:

Block 14214
Code:
Blockheight    Pubkey    Votes

14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    1

Block 14215
Code:
Blockheight    Pubkey    Votes
14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    2
14215    nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE    1

Block 14216
Code:
Blockheight    Pubkey    Votes
14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    2
14215    nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE    2
14216    QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk    1

Block 14217
Code:
Blockheight    Pubkey    Votes
14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    2
14215    nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE    3
14216    QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk    2
14217    Z92SLSwb3z2D47g47Y1E9LczimJiVFtvv    1

Block 14218
Code:
Blockheight    Pubkey    Votes
14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    3
14215    nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE    4
14216    QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk    3
14217    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    1
14218    XomhG7xJcL5iSCQhM4AcS8N381DguAobA    1

So far, so good - each block is appending a vote to the existing votes. But
nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE is receiving votes in each block, too!?
And with the next block the oddness continues

Block 14219
Code:
Blockheight    Pubkey    Votes
14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    3
14216    QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk    4
14217    Z92SLSwb3z2D47g47Y1E9LczimJiVFtvv    1
14218    fqgi8JuLcrrnhkw1JnoCFNqV7qPQSQ85f    1
14219    kSoDShs3inDHZjMBVbLLF4n1YXKMFd8sR    1

Obviously nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE got another vote, and since you lowered MASTERNODE_PAYMENTS_MIN_VOTES to 5 in main.h it got paid out. But additionally the vote for 14218 changed from XomhG7xJcL5iSCQhM4AcS8N381DguAobA to fqgi8JuLcrrnhkw1JnoCFNqV7qPQSQ85f to be changed back to XomhG7xJcL5iSCQhM4AcS8N381DguAobA in the next block - odd!?

Block 14220
Code:
Blockheight    Pubkey    Votes
14214    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    4
14217    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    1
14218    XomhG7xJcL5iSCQhM4AcS8N381DguAobA    1
14219    kSoDShs3inDHZjMBVbLLF4n1YXKMFd8sR    2
14220    YvNsM5mxwbSjM6q2MHifymuTZDjaueE1B    1

And here things get messy: Vote counts for 14214 and 14217 and now inconsistently lowered from 4 to 1.
The next block is odd too:

Block 14221
Code:
Blockheight    Pubkey    Votes
14217    fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o    2
14218    XomhG7xJcL5iSCQhM4AcS8N381DguAobA    2
14219    kSoDShs3inDHZjMBVbLLF4n1YXKMFd8sR    3
14220    YvNsM5mxwbSjM6q2MHifymuTZDjaueE1B    2
14221    dFYvfCtehekxuocBrKewSCNYgg1a5RCtw    1

Vote count for 14217 now changed to 2 (+1), 14218 changed to 2 (+1), 14219 changed to 3 (+1), 14220 changed to 2 (+1) - which would mean this block counted for at least 5 votes?!

So either the abe-explorer is misinterpreting the votes from the blockchain, or the votes are not stored consistently in the blockchain. Can you please dig into this? Thanks!

Holger

EDIT: Seems something is broken with the vote system, votes are stacking up in the same scheme since 14256+ now - which is impossible.

Code:
Blockheight    Pubkey    Votes
142**              ???    5
142**              ???    4
142**              ???    3
142**              ???    2
142**              ???    1

EDIT2:

Verified by 'masternode votes' and 'getblocktemplate', vote system is not counting correctly.

Code:
./darkcoind masternode votes
{
    "14298" : "OP_DUP OP_HASH160 1fed77f7969136e1a4f59b53b34a98c2f6d9a2d6 OP_EQUALVERIFY OP_CHECKSIG",
    "14299" : "OP_DUP OP_HASH160 bce5f22f341d49544ff398a071aac7dfa3bacc4b OP_EQUALVERIFY OP_CHECKSIG",
    "14300" : "OP_DUP OP_HASH160 d8d3cef6e63fa5104f75e2e42a26d69ad9b13dff OP_EQUALVERIFY OP_CHECKSIG",
    "14301" : "OP_DUP OP_HASH160 d3d18906c77e680fb90d8dd0298fdc267d7fecaa OP_EQUALVERIFY OP_CHECKSIG",
    "14302" : "OP_DUP OP_HASH160 5e2a44becdc000fa5331ac7e6f0512d7defe31fe OP_EQUALVERIFY OP_CHECKSIG",
    "14303" : "OP_DUP OP_HASH160 bce5f22f341d49544ff398a071aac7dfa3bacc4b OP_EQUALVERIFY OP_CHECKSIG",
    "14304" : "OP_DUP OP_HASH160 cc9d15a2c7682233f85a8cff39ca1f152221ef3c OP_EQUALVERIFY OP_CHECKSIG",
    "14305" : "OP_DUP OP_HASH160 f860d685867e1f1768bdc22bbcacf7a2a9ee2c31 OP_EQUALVERIFY OP_CHECKSIG",
    "14306" : "OP_DUP OP_HASH160 81e9482117114c4d9fbe0d2851b663931a58d0cd OP_EQUALVERIFY OP_CHECKSIG",
    "14307" : "OP_DUP OP_HASH160 81e9482117114c4d9fbe0d2851b663931a58d0cd OP_EQUALVERIFY OP_CHECKSIG"
}

./darkcoind getblocktemplate
[...]
    "votes" : [
        "df370000000000001976a914bce5f22f341d49544ff398a071aac7dfa3bacc4b88ac05000000",
        "e0370000000000001976a914cc9d15a2c7682233f85a8cff39ca1f152221ef3c88ac04000000",
        "e1370000000000001976a914f860d685867e1f1768bdc22bbcacf7a2a9ee2c3188ac03000000",
        "e2370000000000001976a91481e9482117114c4d9fbe0d2851b663931a58d0cd88ac02000000",
        "e3370000000000001976a91481e9482117114c4d9fbe0d2851b663931a58d0cd88ac01000000"
    ],
    "payee" : "mp6rSxNV1gtSB2KMFDLMkEK6pcFQgEGfXC",
    "masternode_payments" : true
}
[...]

Last two lines should read

Code:
"e237 0000000000001976a914 81e9482117114c4d9fbe0d2851b663931a58d0cd88ac _01_ 000000",
"e337 0000000000001976a914 81e9482117114c4d9fbe0d2851b663931a58d0cd88ac _02_ 000000"

after receiving two votes for 81e9482...

Thanks for the super detailed report. So what you posted actually looks fine. I'll try to explain what's happening.

Block 14217
Code:
Blockheight    Pubkey    Votes
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
 
hmm, try restarting your client and let me know if you get the full list. If so I think I know what's causing that.
I restarted one MN and now it only sees himself
Code:
{
    "188.226.248.36:19999" : 1
}

Should I look for something in the log?

EDIT:
About 30m later another node shows up
Code:
{
    "188.226.248.36:19999" : 1,
    "98.165.130.67:19999" : 1
}

Same behaviour as before
 
Last edited by a moderator:
Thanks for the super detailed report. So what you posted actually looks fine. I'll try to explain what's happening.
[...]

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

Code:
Blockheight    Pubkey    Votes
*              *          4
*              *          3
*              *          2
*              *          1

All normal, all pubkeys have been confirmed in sequence till now

Code:
Blockheight    Pubkey    Votes
*              A          2
*              *          4
*              *          3
*              *          2
*              *          1
Exception - pubkey A was only confirmed 2 times and will be removed if not confirmed further during the next rounds (maximum 10). Either the node is not available anymore, or its presence is not propagated in the network yet - Time will tell.

So what you built with DRKs voting system is basically a blockchain (confirmed votes) inside the blockchain (confirmed blocks) - you are a genius man!

Thanks again,
Holger
 
Last edited by a moderator:
HI all, after a whole night's sleep, I have 67 masternodes on one MN's list, and 66 masternodes on the other. And the one that is missing happens to be my other one, LOL. Yah weird. Glad Evan says he thinks he knows what's causing this, so hopefully it'll get an easy fix.
 
eduffield said:
hmm, try restarting your client and let me know if you get the full list. If so I think I know what's causing that.

Restarting the daemon purges the list and it only slowly starts to be filled again.

Code:
xxx@lvps87-230-94-57:~$ cat .darkcoin/testnet3/debug.log | grep masternode | grep dsee
2014-06-05 11:56:15 dsee - Got NEW masternode entry 54.209.226.236:19999
2014-06-05 11:56:15 dsee - Accepted masternode entry -1 -1
2014-06-05 12:05:24 dsee - Got NEW masternode entry 108.61.199.47:19999
2014-06-05 12:05:24 dsee - Accepted masternode entry -1 -1
2014-06-05 13:48:11 dsee - Got NEW masternode entry 93.188.161.89:19999
2014-06-05 13:48:11 dsee - Accepted masternode entry -1 -1
2014-06-05 14:24:23 dsee - Got NEW masternode entry 188.226.248.36:19999
2014-06-05 14:24:23 dsee - Accepted masternode entry -1 -1
2014-06-05 15:02:31 dsee - Got NEW masternode entry 98.165.130.67:19999
2014-06-05 15:02:31 dsee - Accepted masternode entry -1 -1
 
Last edited by a moderator:
After a couple of hours, I only see 6 MN's, but I am getting rewards, 3 so far. So looking good!

ubuntu@ip-172-31-23-208:~$ darkcoind masternode list
{
"54.209.226.236:19999" : 1,
"108.61.199.47:19999" : 1,
"87.230.94.57:19999" : 1,
"93.188.161.89:19999" : 1,
"188.226.248.36:19999" : 1,
"98.165.130.67:19999" : 1

ubuntu@ip-172-31-23-208:~$ darkcoind masternode votes
{
"14484" : "OP_DUP OP_HASH160 657d9a4ae40b3f1685c4e7c1e8060afbed55657c OP_EQUALVERIFY OP_CHECKSIG",
"14485" : "OP_DUP OP_HASH160 55d0369b6bc7adb2f21688a0c876e3a2c85e5c1c OP_EQUALVERIFY OP_CHECKSIG",
"14486" : "OP_DUP OP_HASH160 9dc1950a2fb3efa64639b4324ff105d53f46822b OP_EQUALVERIFY OP_CHECKSIG",
"14487" : "OP_DUP OP_HASH160 9dc1950a2fb3efa64639b4324ff105d53f46822b OP_EQUALVERIFY OP_CHECKSIG",
"14488" : "OP_DUP OP_HASH160 e3c2bf5d17901d8cf423b787aa5146994837d81a OP_EQUALVERIFY OP_CHECKSIG",
"14489" : "OP_DUP OP_HASH160 9dc1950a2fb3efa64639b4324ff105d53f46822b OP_EQUALVERIFY OP_CHECKSIG",
"14490" : "OP_DUP OP_HASH160 e3c2bf5d17901d8cf423b787aa5146994837d81a OP_EQUALVERIFY OP_CHECKSIG",
"14491" : "OP_DUP OP_HASH160 51ec377004cca3c27ad8450c130717413f7fe8a5 OP_EQUALVERIFY OP_CHECKSIG",
"14492" : "OP_DUP OP_HASH160 55d0369b6bc7adb2f21688a0c876e3a2c85e5c1c OP_EQUALVERIFY OP_CHECKSIG",
"14493" : "OP_DUP OP_HASH160 9dc1950a2fb3efa64639b4324ff105d53f46822b OP_EQUALVERIFY OP_CHECKSIG"
}

{
"account" : "0",
"address" : "moLhAGqnkxN5K9ptRrPbhrCMHDhyr7YGUg",
"category" : "immature",
"amount" : 15.10000000,
"confirmations" : 41,
"generated" : true,
"blockhash" : "00000000c24e47d5e1d3d8e34e6390fd15900c4ce1ff2a7969b0bf97fdc9f6f6",
"blockindex" : 0,
"blocktime" : 1401975109,
"txid" : "baffe57a3886bf214bfc450dcc1290cb08c2ba872c003cb7cb9641efef6e94bf",
"time" : 1401975109,
"timereceived" : 1401975127
},
{
"account" : "0",
"address" : "moLhAGqnkxN5K9ptRrPbhrCMHDhyr7YGUg",
"category" : "immature",
"amount" : 15.10000000,
"confirmations" : 29,
"generated" : true,
"blockhash" : "00000001e7a9ef1a94639864217c03cdfada859a78265a1d9019bcea25f08b51",
"blockindex" : 0,
"blocktime" : 1401976638,
"txid" : "9d686f604989611d840bd70bbc5b94bf75df92ef83329c19861d882a38f6775f",
"time" : 1401976638,
"timereceived" : 1401976666
},
{
"account" : "0",
"address" : "moLhAGqnkxN5K9ptRrPbhrCMHDhyr7YGUg",
"category" : "immature",
"amount" : 15.00000000,
"confirmations" : 1,
"generated" : true,
"blockhash" : "00000000acfee875cc75e9e62a13cc8984c85272f632d61233b62137cf5b12bf",
"blockindex" : 0,
"blocktime" : 1401980615,
"txid" : "7bb408cafbb2f9491ce1a98e68850573176db08603c8d5b979f8237b19b678d8",
"time" : 1401980615,
"timereceived" : 1401980654
}
 
After a couple of hours, I only see 6 MN's, but I am getting rewards, 3 so far. So looking good!

After what i learned from Evan about the voting system now, the list of MNs of a masternode does not matter - as long as your node is in the list of each pool/miner you should get voted and paid :smile:

P2Pool for DRK should include a statistics page for the MN list, so that the MN owner can check against the pools if their MN is alive and included in the votes.
 
Restarting the daemon purges the list and it only slowly starts to be filled again.

Code:
xxx@lvps87-230-94-57:~$ cat .darkcoin/testnet3/debug.log | grep masternode | grep dsee
2014-06-05 11:56:15 dsee - Got NEW masternode entry 54.209.226.236:19999
2014-06-05 11:56:15 dsee - Accepted masternode entry -1 -1
2014-06-05 12:05:24 dsee - Got NEW masternode entry 108.61.199.47:19999
2014-06-05 12:05:24 dsee - Accepted masternode entry -1 -1
2014-06-05 13:48:11 dsee - Got NEW masternode entry 93.188.161.89:19999
2014-06-05 13:48:11 dsee - Accepted masternode entry -1 -1
2014-06-05 14:24:23 dsee - Got NEW masternode entry 188.226.248.36:19999
2014-06-05 14:24:23 dsee - Accepted masternode entry -1 -1
2014-06-05 15:02:31 dsee - Got NEW masternode entry 98.165.130.67:19999
2014-06-05 15:02:31 dsee - Accepted masternode entry -1 -1

Opps. I found what's causing that. It'll be fixed when I push new binaries.
 
How will we be able to check and see if we are on the list of the pool miners? I know I'm not the only person who will be anxious to have confirmation that we're up and running properly :tongue:

Ok, great to know, LOL

Question: Has anyone sent funds out of their masternode account to another account while the masternode was running, and did the masternode continue to run properly? I just did that, hope it continues to run without issue.

Oh cool, I just tried sending out more than my "extra coins" and I got an "insufficient funds" error, so that's all good. Looks like we can withdraw our extra funds (successfully sent some funds before that) and when we try to send even a small portion that cuts into the 1000 coins, we will get an error. And all this can be done while the MN is running, so no interruption.

You all probably already knew that, but I never tried, LOL

So I'm trying to mess with the masternode and cause trouble, so I setgenerate true to start mining, and it seems to have let me do this. Am I mining as a Masternode for real?
 
Last edited by a moderator:
Question: Has anyone sent funds out of their masternode account to another account while the masternode was running, and did the masternode continue to run properly? I just did that, hope it continues to run without issue.

I guess my question is, when sending funds out of a masternode, do the funds come out of the MN payment addresses? I mean, does it leave the one time payment into the MN of 1000 dark alone?

Yes I sent funds from running masternodes with no issues so far... but I never took enough to leave the balance below 1k.
 
Not a coder, so since my node is working and getting rewards, I'll try to test the following

1) stop the node and time how long it takes to get off http://tdrk.poolhash.org/blocks/masterlist.txt
2) update and fire up my 2nd node and confirm success, and repeat step 1) again

I will then test local.online/remote. I have two VM Ubuntus in my Mac under the same router, but treated and physical machines. Any technical reason why two (or more) DHCP independent VM's under the same external IP could not control their own remote node?
 
Last edited by a moderator:
Yes I sent funds from running masternodes with no issues so far... but I never took enough to leave the balance below 1k.

To be clear, have you tried to send more than the remaining 1000 DRK? For instance, your balance is 1555 DRK. If you send out 556, will it just allow it and deactivate the node, or will is it "locked" with the masternode=1 flag?
 
To be clear, have you tried to send more than the remaining 1000 DRK? For instance, your balance is 1555 DRK. If you send out 556, will it just allow it and deactivate the node, or will is it "locked" with the masternode=1 flag?
I tried it now and got:
Code:
error: {"code":-4,"message":"Insufficient funds"}
as expected :grin:
 
I tried it now and got:
Code:
error: {"code":-4,"message":"Insufficient funds"}
as expected :grin:

I think you can spend it using copied wallet on other computer.
Not clear when network will invalidate spent Masternode.
1) as soon as tx received
2) tx get confirmed
 
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

Code:
Blockheight    Pubkey    Votes
*              *          4
*              *          3
*              *          2
*              *          1

All normal, all pubkeys have been confirmed in sequence till now

Code:
Blockheight    Pubkey    Votes
*              A          2
*              *          4
*              *          3
*              *          2
*              *          1
Exception - pubkey A was only confirmed 2 times and will be removed if not confirmed further during the next rounds (maximum 10). Either the node is not available anymore, or its presence is not propagated in the network yet - Time will tell.

So what you built with DRKs voting system is basically a blockchain (confirmed votes) inside the blockchain (confirmed blocks) - you are a genius man!

Thanks again,
Holger

I understand everything to the point where a node is chosen to be paid. Do the last 6 votes select the node to be chosen or is it only the miner which will randomly pick one?
 
Status
Not open for further replies.
Back
Top