v0.10.9.x Help test RC2 forking issues

Status
Not open for further replies.
yidakee said:
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?
Click to expand...
you get an insufficient funds error :)

Well, actually, that's when you have the funds on your MN.... I think it's time for me to try a remote MN, and see what happens when I try to send extra funds... this I don't know about :D
 
vertoe said:
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?
Click to expand...

Actually the node chosen is NOT random, it's deterministic. So if you have the FULL list you WILL get the correct masternode. Once the propagation issues are completely resolved and the ghost masternodes we should have payments on 100% of the blocks.
 
eduffield said:
New binaries are up that should fix the masternode syncing problem.
Please update 9.5.3 or 10.9.3! Thanks!
Click to expand...

Sorry to stress that, but the versionnumbers in this binary mismatch :rolleyes::smile:

Code: 
~/.darkcoin$ strings darkcoind | grep v0.1
v0.10.9.3-2-gbed3449-beta

~/.darkcoin$ ./darkcoind getinfo
{
    "version" : 100904,
[...]
 
eduffield said:
New binaries are up that should fix the masternode syncing problem.
Please update 9.5.3 or 10.9.3! Thanks!
Click to expand...

Updated. 7 nodes in list. Equal in the 2 MNs :smile:
Code: 
{
    "87.230.94.57:19999" : 1,
    "37.187.47.129:19999" : 1,
    "98.165.130.67:19999" : 1,
    "184.73.179.148:19999" : 1,
    "188.226.133.22:19999" : 1,
    "188.226.248.36:19999" : 1,
    "54.255.159.230:19999" : 1
}

Version reported is 10.9.4
Code: 
{
    "version" : 100904,
    "protocolversion" : 70015,
    "walletversion" : 60000,
    "balance" : 4668.75789292,
    "blocks" : 14523,
    "timeoffset" : 0,
    "connections" : 4,
    "proxy" : "",
    "difficulty" : 0.32486492,
    "testnet" : true,
    "keypoololdest" : 1401700391,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00001000,
    "errors" : ""
}
 
Yep, nodes come in a lot faster now.

Code: 
xxx@lvps87-230-94-57:~$ cat .darkcoin/testnet3/debug.log | grep masternode | grep dsee
2014-06-05 16:33:08 dsee - Got NEW masternode entry 87.230.94.57:19999
2014-06-05 16:33:08 dsee - Accepted masternode entry 0 0
2014-06-05 16:34:43 dsee - Got NEW masternode entry 37.187.47.129:19999
2014-06-05 16:34:43 dsee - Accepted masternode entry -1 -1
2014-06-05 16:40:24 dsee - Got NEW masternode entry 98.165.130.67:19999
2014-06-05 16:40:24 dsee - Accepted masternode entry -1 -1
2014-06-05 16:44:21 dsee - Got NEW masternode entry 184.73.179.148:19999
2014-06-05 16:44:21 dsee - Accepted masternode entry -1 -1
2014-06-05 16:46:48 dsee - Got NEW masternode entry 188.226.133.22:19999
2014-06-05 16:46:48 dsee - Accepted masternode entry -1 -1
2014-06-05 16:47:06 dsee - Got NEW masternode entry 188.226.248.36:19999
2014-06-05 16:47:06 dsee - Accepted masternode entry -1 -1
2014-06-05 16:49:08 dsee - Got NEW masternode entry 54.255.159.230:19999
2014-06-05 16:49:08 dsee - Accepted masternode entry -1 -1
 
BrainShutdown said:
Updated. 7 nodes in list. Equal in the 2 MNs :smile:
Code: 
{
    "87.230.94.57:19999" : 1,
    "37.187.47.129:19999" : 1,
    "98.165.130.67:19999" : 1,
    "184.73.179.148:19999" : 1,
    "188.226.133.22:19999" : 1,
    "188.226.248.36:19999" : 1,
    "54.255.159.230:19999" : 1
}

Version reported is 10.9.4
Click to expand...

Not updated yet, in fact just updated my second node to 9.3 and have the exact same nodes listed. One is the one I just set up the other has gone. Going to update everything again.

Cant seem to get the new sync fix (pun intended) :tongue:
--2014-06-05 17:09:01-- http://www.darkcoin.io/downloads/rc3/darkcoind
Resolving www.darkcoin.io (www.darkcoin.io)... 162.252.83.46
Connecting to www.darkcoin.io (www.darkcoin.io)|162.252.83.46|:80... connected.
HTTP request sent, awaiting response...
Click to expand...

... but with patience it got here...
 
Last edited by a moderator:
eduffield said:
Actually the node chosen is NOT random, it's deterministic. So if you have the FULL list you WILL get the correct masternode. Once the propagation issues are completely resolved and the ghost masternodes we should have payments on 100% of the blocks.
Click to expand...

Seems updating the nodes is confusing the network - or did you raise the number of vote confirmations, too?

Block 14538

Code: 
Blockheight    Pubkey    Votes
14530    Ra2X7HrU58fAw7R2woBGwcrqV9SXGbSX1    8
14531    nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE    8
14532    b5iJWY1uVwGzEhypkVo4sWZXyU7CkLjWx    7
14533    kSoDShs3inDHZjMBVbLLF4n1YXKMFd8sR    3
14534    XomhG7xJcL5iSCQhM4AcS8N381DguAobA    5
14535    VkZWihGicV2obp7tGCA3zByq2wLxLg893    2
14536    b5iJWY1uVwGzEhypkVo4sWZXyU7CkLjWx    2
14537    bxxXpVhzZsxdxujH2Axgps8cJ5KFHvKfq    2
14538    c1QoaTBRDyhFmQov3R1Yo2zCZMnim9hXo    1
 
I just updated both my nodes.

MN-1 worked straight away 10.9.4, sending 1k to address 0
MN-2 was working 10.9.3, updated to 10.9.4 = not capable masternode - I checked and I do still have 1K @ address 0 - also tried a new genkey... dont know what might be wrong!

suggestions?
 
Last edited by a moderator:
yidakee said:
I just updated both my nodes.

MN-1 worked straight away 10.9.4, sending 1k to address 0
MN-2 was working 10.9.3, updated to 10.9.4 = not capable masternode - I checked and I do still have 1K @ address 0 - also tried a new genkey... dont know what might be wrong!

suggestions?
Click to expand...
You could try to generate new address for account 0 and sendo the 1k to yourself to the new address and wait for the confirmations.
 
How does the new version deal with MN using (intentionally or not) an old version ?
 
BrainShutdown said:
Other thing that got me is this entry

192.168.55.55:19999 : 1,

in http://tdrk.poolhash.org/blocks/masterlist.txt

it's a private network ip. How did it get up there? :grin:
Click to expand...

Sorry about that :smile: I thought I had changed it back. I setup my MN (using remote/local method) on the local LAN. The first time I did it (v10.9.2) it worked and published the public IP address of the remote. Second time I did it with v 10.9.3, it published the private IP address of the remote.

I thought I had turned it off, and turned on with the right IP address 23.242.106.27 and I also have a MN payment in the wallet mnKjtxAsabarv2y2kb3sGyHz7rFEnm7Uu4 (15 DRK), but I dunno anymore, lol. I'm gonna start over a little bit later with v 10.9.4 and use the public IP when I set up the remote/local MN.
 
daaarkcoins said:
Don't bother, the same thing happens ;)
Click to expand...
Good thing to know :)

I have a question about voting. Where are the masternodes chosen to be voted upon? I mean, there are only 5/6 to vote on, how are they chosen? And when they never get voted "into office", what happens?
 
Well, I believe I began mining with my masternodes (used setgenerate true on them) and one of my masternodes has received a payment since then, so if it's really mining (no real way to tell), it doesn't interfere with masternode functions I guess, LOL. Not that a single core will ever find a masternode, and probably will slow the system down, but funny anyway.

I'm going to update when I get back from taking daughter to school (college). I need to purchase a hard drive 'cause I'm going to do remote setup. Unfortunately, my internet connection isn't all that great, it goes out periodically. So Evan, if you're reading this, please work on a cold storage solution, LOL.
 
TanteStefana said:
[...] I need to purchase a hard drive 'cause I'm going to do remote setup. Unfortunately, my internet connection isn't all that great, it goes out periodically. So Evan, if you're reading this, please work on a cold storage solution, LOL.
Click to expand...
Authorizing the cold storage for a MN is, in my opinion, a big can of worms. Using a remote setup server---->server instead of local----->server seems to be, for me, the best solution.

What prevents somebody to move around the funds, and create 10 MN with the same 1000 DRK.
If the address is monitored with a new parameter like "coldaddress=Xxxxxxxxxxxxxxxxxx", what prevents somebody to use an address, which does not belong to him, but with the right amount to setup a masternode ?
 
Last edited by a moderator:
Kai said:
Authorizing the cold storage for a MN is, in my opinion, a big can of worms. Using a remote setup server---->server instead of local----->server seems to be, for me, the best solution.

What prevents somebody to move around the funds, and create 10 MN with the same 1000 DRK.
If the address is monitored with a new parameter like "coldaddress=Xxxxxxxxxxxxxxxxxx", what prevents somebody to use an address, which does not belong to him, but with the right amount to setup a masternode ?
Click to expand...
You could sign the 1000DRK Masternode address to an IP. Once they get moved or signed to another IP the first one gets removed from the masternode list.
No problem. No can of worms ;)
 
Last edited by a moderator:
eduffield said:
Actually the node chosen is NOT random, it's deterministic. So if you have the FULL list you WILL get the correct masternode. Once the propagation issues are completely resolved and the ghost masternodes we should have payments on 100% of the blocks.
Click to expand...
Please give us more information on the Voting system or maybe it is classified.
 
Status
Not open for further replies.
Back
Top