V12 Release

Minotaur said:
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.
Click to expand...
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.
 
cwnage said:
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).
Click to expand...
---
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.
 
Lariondos said:
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.
Click to expand...
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...
 
Lebubar said:
It seems that my upgraded MN are going offline after a while.
Click to expand...

ceti said:
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
Click to expand...

GilAlexander said:
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?
Click to expand...

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.
 
moli said:
nmarley - I guess we're not going to see that feature again. Sorry.
Click to expand...

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.
 
Lebubar said:
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?
Click to expand...
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.
 
Lariondos said:
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.
Click to expand...
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??
 
Lariondos said:
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.
Click to expand...

Indeed, the 70102 protocol version was an error. I'm pushing up new binaries as we speak.
 
You must log in or register to reply here.
Back
Top