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

v0.11.0 - Darkcoin Core Release

I just updated all my nodes to 11.0.11. I was able to "start" each from the cold wallets and got a "Successfully started Masternode" message. However, each node's log continues to repeat the following:

Code:
2015-01-21 17:52:43 CActiveMasternode::ManageStatus() - Checking inbound connection to '54.xxx.xxx.xxx:9999'
2015-01-21 17:52:43 CActiveMasternode::GetMasterNodeVin - Could not locate specified vin from possible list
2015-01-21 17:52:43 CActiveMasternode::ManageStatus() - Could not find suitable coins!
2015-01-21 17:52:43 CActiveMasternode::Dseep() - Error: masternode is not in a running status
2015-01-21 17:52:43 CActiveMasternode::ManageStatus() - Error on Ping: masternode is not in a running statusconnected to self at 54.xxx.xxx.xxx:50995, disconnecting

ALSO:
Code:
2015-01-21 17:56:50 connection from xx.xxx.xx.xxx:35455 dropped (banned)   - Where the ip address here that I have masked with "x" is the ip of my local cold wallet machine.


All nodes, even ones that I have not tried to start yet still show in the masternode list. This might be because I only just updated though.

Any ideas? I was able to update to v.10 fine yesterday.


EDIT:

Right after I execute masternode start in the local wallet I see this in the log of the remote:

Code:
2015-01-21 18:06:55 dseg - Sent 585 masternode entries to xx.xxx.xx.xx:35644
2015-01-21 18:06:55 Misbehaving: xx.xxx.xx.xx:38717 (0 -> 100) BAN THRESHOLD EXCEEDED
2015-01-21 18:06:55 dseg - peer already asked me for the list
2015-01-21 18:06:55 mnget - Sent masternode winners to 69.xxx.xx.xxx:35644
 
Last edited by a moderator:
I just updated all my nodes to 11.0.11.

did you update your local wallet too?
v0.11.0.11 will only accept start signals from v0.11.0.11

You'll probably want to stop your nodes, delete peers.dat and restart them to get a fresh un-banned start too.
 
I got the same problem, but only on one node, not the others. Normally I dont look at debug.log, but this time I did so i noticed. The masternode also shows with a :1 like you described, but the debug log does not tell it was successfully activated, just this:
The same, tons of it. Log is 270mb after an hour.
 
Nice Tools menu in this version where to find the Debug console:

upload_2015-1-21_13-55-41.png


In previous versions before v.110011:

upload_2015-1-21_13-57-14.png
 
After multiple attempts to get my MN:s online after v11 update, i give up and MN:s can have a day off.

Local say started succesfully, but remote is still offline.
 
did you update your local wallet too?
v0.11.0.11 will only accept start signals from v0.11.0.11

You'll probably want to stop your nodes, delete peers.dat and restart them to get a fresh un-banned start too.

Yep. local wallet is .11 Mac. Updating that was the 1st thing I did. Deleted peers.dat on all locals and MNs. Even tried doing a full restart on two of the nodes, no change in behavior.
Nodes are now dropping off the masternode list, which makes sense it's been just over an hour. So they are definitely not active
 
Yep. local wallet is .11 Mac. Updating that was the 1st thing I did. Deleted peers.dat on all locals and MNs. Even tried doing a full restart on two of the nodes, no change in behavior.
Nodes are now dropping off the masternode list, which makes sense it's been just over an hour. So they are definitely not active

odd. is behaving like it's a protocol mismatch. do 'getinfo' in your local and remote and verify these two values match:

Code:
"version" : 110011,
"protocolversion" : 70054,
 
All my MNs decided to take a lunchbreak and leave their deamons still running. Thankfully start-many makes whipping them all back to their slavepits a speedy procedure. No unusual spikes in the stats, they just sloped off.

Some easily grepped marker added to the debug.log like 'MN stopped!' would be handy, if such a thing could be incorporated.
 
odd. is behaving like it's a protocol mismatch. do 'getinfo' in your local and remote and verify these two values match:

Code:
"version" : 110011,
"protocolversion" : 70054,

Yes correct values on both. I can't spend anymore of my workday trying to troubleshoot, bummer. I'll check back in later.

EDIT: Keep in mind I'm getting "Successfully started Masternode' in the local wallet. So at least from that end it thinks it's working.
 
Are you guys monitoring your nodes using drk.mn? Or checking status using SSH?
I mean, how do you know your nodes stopped went offline?
 
Yep. local wallet is .11 Mac. Updating that was the 1st thing I did. Deleted peers.dat on all locals and MNs. Even tried doing a full restart on two of the nodes, no change in behavior.
Nodes are now dropping off the masternode list, which makes sense it's been just over an hour. So they are definitely not active
I'm having the exact same experience with the Mac v11.0.11 client. Masternodes send start successfully show up in the list but then they are dropping out. The complete disregard for mac users of the wallets is how do I put it... annoying?
 
I'm having the exact same experience with the Mac v11.0.11 client. Masternodes send start successfully show up in the list but then they are dropping out. The complete disregard for mac users of the wallets is how do I put it... annoying?
It's not just mac users having this problem.
 
so i waited 2 hours until masternode disappeared from the list. Then started daemon and activation from scratch and now I successful get the "
2015-01-21 21:33:18 CActiveMasternode::EnableHotColdMasterNode() - Enabled! You may shut down the cold daemon.
" message

I've tested v0.11.0.11 with a remote masternode and everything seems to function correctly, nothing was changed that would cause any problems.

However if you run "masternode start" on a remotely activated masternode, it's state will be reset and it'll stop pinging (this existed on all v11 versions). This will be fixed in v0.11.0.12, for the time being if you see "EnableHotColdMasterNode" in the log it should be fine.
 
This will be fixed in v0.11.0.12, for the time being if you see "EnableHotColdMasterNode" in the log it should be fine.

And if you are unable to achieve this? Do you have any suggestions. We have multiple people reporting they aren't ever able to get this expected behavior from windows or mac local mn wallets.
 
I've found that doing start-many won't propagate my MN's unless I issue the start-many command within around 30 seconds of starting the remote daemons.

It appears to be if the remote daemons are updated and fully synced, it seems to disregard the local start-many command. It seems to only accept it while syncing up and retrieving the MN list.
 
And if you are unable to achieve this? Do you have any suggestions. We have multiple people reporting they aren't ever able to get this expected behavior from windows or mac local mn wallets.

I've just made a masternode from scratch on windows and successfully started a remote machine on linux, which in turn started pinging.

1.) Start the remote masternode
2.) Open your local wallet, with the 1000DRK, then type "masternode outputs". You should see the output you're trying to start.
3.) Start the masternode with "masternode start" or "masternode start-alias mn1 'password'"
4.) Look through the remote masternode debug for "EnableHotColdMasterNode", if it says that it's successful. DONT TYPE "masternode start" on the remote side due to the v11 issue (will be fixed in v0.11.0.12)
5.) Next you should see something like
2015-01-22 00:20:49 CActiveMasternode::ManageStatus() - Begin
2015-01-22 00:20:49 CActiveMasternode::Dseep() - SendDarkSendElectionEntryPing vin = CTxIn(COutPoint(xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, 0), scriptSig=)

I'll let my node run for a few hours to make sure it's not dying for some reason. However, everything seems to work.

Let me know if those instructions help or not, I'm curious to figure out what's going on.
 
eduffield One of my MN's has this in the debug file. Should I reindex the daemon?
debug said:
2015-01-22 00:47:53 CheckForkWarningConditions: Warning: Large valid fork found
forking the chain at height 207095 (00000000000fbacc124b1477066f633181bdbf053fbb78a8cb28588d412b206d)
lasting to height 207105 (00000000000243e9009e6c0de9c9313b1552bab3c7756dcd5243a3517544cd11).
Chain state database corruption likely.
2015-01-22 00:47:53 ProcessBlock: ACCEPTED

EDIT: and the daemon has this in getinfo

"errors" : "Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues."
}

EDIT EDIT: One daemon has block count at 207105 another at 207098. Fork?
 
Back
Top