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

V12 Release

As far as I understand it was a security concern. Making it OK for the payments to go to a different address could open unexpected attack vectors, that is what I gathered but I am sure eduffield can clarify.
You are correct. Evan explained this in his post: https://dashtalk.org/threads/v12-testing-thread.5484/page-23#post-57691

(How could i forget that .. too much testing caused memory loss i guess.. lol..)

nmarley - I guess we're not going to see that feature again. Sorry.
 
Don't trust that message, it rarely is correct. It's the "last" message, and because of reindexing, doesnt know coins exist, and does this.

Type "masternode status" (new command) and look for status 4.

Also look for the Pings in debug.log (that means you're broadcasting to the network - happens roughly once a minute).
---
dash-cli masternode status
"status" : 4,
"notCapableReason" : "Could not find suitable coins!"
and
not showing up on masternode list...


Seems like it's very much dependent when you give the masternode start command,
like
start the cold wallet,
wait for it to start (dash-cli getinfo and see connections)
start the masternode wallet, and wait for it to get 1 con
and then masternode start command, and it will fire tight up, if you wait more connection, it wont start and cannot find coins...

or am I imagining things...

Edit: I now got the masternodes up and on to the list, using the above method.
 
It's a bit confusing. If I use the official 0.12.0.44 linux 64 release, I'm running with protocol version 70102. If I use the last 0.12.0.44 from testnet, I get protocol version 70103. So which version is the right one for mainnet now?

Edit: The windows release version is on 70103, the linux 64 bit isn't.
Yes I think this is important. All my MN are in protocol 102, download from oficial site. This can be the problem of passing offline after ~1 hour I start them?
 
Some more details about what I observed so far :
When I start an upgrade MN, I got the message that it start ok.
Himself detected it as Enable, other MN (upgraded in 12.0.44) did not detect it as enable and don't list it. MN with old version detect it correctly. And after sometimes it is delisted from himself and from old ver. MN.

And I also notice this story of protocol version diference.

Edit : i cold start from windows, so protocol 103...so maybe for this didn't keep online...
 
It seems that my upgraded MN are going offline after a while.

Have had mn's drop out twice after about 70-80 minutes, tried cold restart.

they revert back to status '3' when i check in the wallet

I'll try a cold restart again

Same for me. After restarting they appear in ./dash-cli masternodelist full as ENABLED, then as EXPIRED and then dissapear.
./dash-cli masternode status on both hot and cold wallets at all the moments shows smth like
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "goodmnip:9999",
"status" : 3,
"pubKeyMasternode" : "XkdxDim3T4NsBH5Tij8TRwNNJA47qtujj7", <- dunno what is it
"notCapableReason" : "Could not find suitable coins!"
}
Is it because unable to "sync masternodes list" and will it fix itself after the whole network updated?

All this was exactly what was happening to me yesterday, I had to restart all of them, and they never came up with status 4, only status 3 as shown in my previous posts. Eventually downgraded back to v11, a more stable version.
 
nmarley - I guess we're not going to see that feature again. Sorry.

I don't see any reason not to bring it back up if a large enough portion of the community wants it. Sure, it's an attack vector. But that's a risk MN operators would have to accept -- secure your masternode.conf file. It seems that to simply state "no, that's not going to happen because security" without discussion doesn't make it a very collaborative process — even if Evan's the one who said it. There are other security professionals in the community, and there are probably other ways of implementing it as well.
 
My masternodes first started ok, enabled, all ok.
Then later all dropped of the list, and now some mn:s even does not start anymore or cant get them enabled.
DS compatiple masternode count does not grow because they are dropping from the list.

Waiting new version or info about this.
 
Yes I think this is important. All my MN are in protocol 102, download from oficial site. This can be the problem of passing offline after ~1 hour I start them?
With all my MN on 70103 I also observe dropping off an on randomly. On dashninja some of them are partially unlisted or partially inactive.

Edit: Ok, let's wait for a solution.
 
With all my MN on 70103 I also observe dropping off an on randomly. On dashninja some of them are partially unlisted or partially inactive.

Edit: Ok, let's wait for a solution.
My linux masternodes show 70102 protocol ver, and win qt wallet show 70103.
 
Looks like the masternode.conf file is automatically generated now, so I'm wondering if we need a masternode.conf file in both the hot and the cold wallet now (if we're using start-many) or if it's even required no matter (IE, the old dash.conf only setup is no longer valid) 'cause I used the dash.conf setup throughout testnet??
 
With all my MN on 70103 I also observe dropping off an on randomly. On dashninja some of them are partially unlisted or partially inactive.

Edit: Ok, let's wait for a solution.

Indeed, the 70102 protocol version was an error. I'm pushing up new binaries as we speak.
 
Back
Top