V12 Testing Thread

[bertlebbert]

I'm not using start-many on testnet. All my testnet nodes are hot nodes.



I'm pretty sure the command returns successful if it is able to connect and send data to the iport of the masternode. I don't think (could be wrong, haven't read code) it uses any response from the remote side.

I dunno, he asked me for a list of my nodes, next thing I saw status REMOVED using masternodelist full, so I did a start-many, and everything looked fine. But when I told him that, he said it is impossible - as daemon not running. Eventually they show on list as DISABLED, so we repeat the process... and that's all I know

 

[moocowmoo]

I dunno, he asked me for a list of my nodes, next thing I saw status REMOVED using masternodelist full, so I did a start-many, and everything looked fine. But when I told him that, he said it is impossible - as daemon not running. Eventually they show on list as DISABLED, so we repeat the process... and that's all I know

Keep in mind we're dealing with a network cache.

Masternode 'start'ing is nothing more than a signed (by the masternodeprivkey associated with a particular masternode) packet with a particular protocol number, ip, port, vin, and index (all the stuff in masternode.conf) bouncing around the masternode network.

That packet's lifetime is 70 minutes last time I checked.

The masternode that the packet refers to needs to be alive and responsive for that packet to stay in the cache.
(and probably more behaviors I've not checked the code for, perhaps it needs to be re-broadcast by the referenced node, or have some nonce or timestamp updated, dunno -- UdjinM6 , eduffield -- want to chime in on this? Will/has removing pose in v12 affected this?)

Start-many is just the same start above performed multiple times using a source list.

I don't know how a hot node differs, but I'd guess it uses the same packet mechanism.
Maybe a hot node (what I'm running) can do something that a cold-node cannot in v12?

 

[UdjinM6]

Keep in mind we're dealing with a network cache.

Masternode 'start'ing is nothing more than a signed (by the masternodeprivkey associated with a particular masternode) packet with a particular protocol number, ip, port, vin, and index (all the stuff in masternode.conf) bouncing around the masternode network.

That packet's lifetime is 70 minutes last time I checked.

The masternode that the packet refers to needs to be alive and responsive for that packet to stay in the cache.
(and probably more behaviors I've not checked the code for, perhaps it needs to be re-broadcast by the referenced node, or have some nonce or timestamp updated, dunno -- UdjinM6 , eduffield -- want to chime in on this? Will/has removing pose in v12 affected this?)

Start-many is just the same start above performed multiple times using a source list.

I don't know how a hot node differs, but I'd guess it uses the same packet mechanism.
Maybe a hot node (what I'm running) can do something that a cold-node cannot in v12?

Yep, hot masternode had more checks

Regarding how it works
- still need separate vin with 1000 DASH to spam network
- every MN should send signed ping message every (15 on v11, 30 on v12) minutes and will drop off the list if no ping was received in 70 minutes. In v12 ping message also contain one of the latest block hashes and that should help to kick stuck MNs off the list too.
- ref node is no more here but it never rebroadcasted anything specific about that, actually every client holds initial signed messages of every MN it knows and send it to someone who asked for it. In v12 such response also contains latest known signed ping so I hope MN list should be a bit more consistent now.

bertlebbert
Fixes for local checks https://github.com/dashpay/dash/pull/438 :smile:
However implementing network wide protection will take some (yet unknown) amount of time

 

[bertlebbert]

Keep in mind we're dealing with a network cache.

Masternode 'start'ing is nothing more than a signed (by the masternodeprivkey associated with a particular masternode) packet with a particular protocol number, ip, port, vin, and index (all the stuff in masternode.conf) bouncing around the masternode network.

That packet's lifetime is 70 minutes last time I checked.

The masternode that the packet refers to needs to be alive and responsive for that packet to stay in the cache.
(and probably more behaviors I've not checked the code for, perhaps it needs to be re-broadcast by the referenced node, or have some nonce or timestamp updated, dunno -- UdjinM6 , eduffield -- want to chime in on this? Will/has removing pose in v12 affected this?)

Start-many is just the same start above performed multiple times using a source list.

I don't know how a hot node differs, but I'd guess it uses the same packet mechanism.
Maybe a hot node (what I'm running) can do something that a cold-node cannot in v12?

My main curiosity here was how actually accurate and up-to-date is result provided using "masternodelist full" command?

 

[bertlebbert]

Yep, hot masternode had more checks

Regarding how it works
- still need separate vin with 1000 DASH to spam network
- every MN should send signed ping message every (15 on v11, 30 on v12) minutes and will drop off the list if no ping was received in 70 minutes. In v12 ping message also contain one of the latest block hashes and that should help to kick stuck MNs off the list too.
- ref node is no more here but it never rebroadcasted anything specific about that, actually every client holds initial signed messages of every MN it knows and send it to someone who asked for it. In v12 such response also contains latest known signed ping so I hope MN list should be a bit more consistent now.

bertlebbert
Fixes for local checks https://github.com/dashpay/dash/pull/438 :smile:
However implementing network wide protection will take some (yet unknown) amount of time

Cool! Good to hear you guys are on it!

 

[moocowmoo]

My main curiosity here was how actually accurate and up-to-date is result provided using "masternodelist full" command?

That was the point I was trying to get at. That you're looking at the state of the cache, rather than the state of the network.
Which presumably will update the cache to match the state of the network, over time.
If nobody sends any start signals, the cache should be representative of the network, as I understand things.

 

[UdjinM6]

My main curiosity here was how actually accurate and up-to-date is result provided using "masternodelist full" command?

That depends on what you mean by that

masternode list gives you all the latest and actual info your node knows.
In ideal world that would be exactly the same info on every node.
In our world there is always a difference because:
- some nodes may stuck - happens quite often on v11 these days, I we can make hope v12 to deal with that better
- some nodes may be banned by some others (24h by default) and may be not banned by yet another nodes - inevitable difference because nodes communicate directly to some limited number of nodes, we can't just connect everyone to everyone and we can't trust to someone's else banscore.
- some nodes come, some nodes go, different nodes count them differently on v11 - that's why there are changes to broadcast and ping messages I talked above. That part should be more stable now.
So the whole picture of MN network is kind of jelly but most part of it (in normal conditions) should be pretty stable now (I really hope so :grin

 

[moli]

All my wallets were shut down about 12 hours ago, Now I'm trying to start them, 2 got synced fine, but 4 wallets are stuck.
I know I can get them synced by deleting budget.dat, using -reindex... etc... but I thought this issue was already solved in v.12.0.20?

Note: At the time of this post writing the current block height on testnet is 85498 according to http://test.insight.dash.siampm.com/

 

[moocowmoo]

- still need separate vin with 1000 DASH to spam network

Can you explain why we find multiple vins attached to one ip in the v11 network? Is this prohibited in v12?

darkcoind masternode list full | grep 37.157.250.24
"   37.157.250.24:9999" : "   ENABLED 70075 XvWmB8BnDdi2awESuJuBtvzGpFrq4hBfe1 ff081b33c986999f4726e06cde07209033b724edc29dbbcf2314b244f5fa93ab 1437181877  8577106",
"   37.157.250.24:9999" : "   ENABLED 70076 Xdj6dTMj8YPUwg6wiBrSKxsPm1z7eGf4bv 3494da9c8b6afdad6979d4c6ba340623647948556a45a8c16db24b68cd0463af 1437181881   182075",
"   37.157.250.24:9999" : "   ENABLED 70076 XprANFv11sTjvHrT3qNWx2LQE2cTae28uU ae5390452a36668e7e9b8f2c18857587bb9e635942f757c175e65b7511947f1d 1437181811   181992",
"   37.157.250.24:9999" : "   ENABLED 70076 XuwpR4fE7rKWikEJZaMoc22zgr79FJso2D 9e81cafc66ffd26e8c3091d7f46f2b1ba097582f5ba1c1d32a6e01e7ec345264 1437181811   181993",

- every MN should send signed ping message every (15 on v11, 30 on v12) minutes and will drop off the list if no ping was received in 70 minutes. In v12 ping message also contain one of the latest block hashes and that should help to kick stuck MNs off the list too.

Will you elaborate on how a cold node can sign the ping message?

 

[strix]

All my wallets were shut down about 12 hours ago, Now I'm trying to start them, 2 got synced fine, but 4 wallets are stuck.
I know I can get them synced by deleting budget.dat, using -reindex... etc... but I thought this issue was already solved in v.12.0.20?

Note: At the time of this post writing the current block height on testnet is 85498 according to http://test.insight.dash.siampm.com/

View attachment 1613

Once again, i find the preponderance of terminal nines interesting. Is this just a coincidence?

Ref. my previous post copied below...

Just fired up V. .20 with --reindex but did NOT delete any files. Sync flew past 75799, but got hung on 84999 @ 14 hours. Will retry with files deleted.

Edit: Interesting--I simply restarted the client without --reindex and it dutifully continued syncing up to block 85299 at T- 1 hour where it hung again. Will try simply restarting again and report back shortly.

Edit2: Nope, no joy--still hung on 85299. Will proceed to delete files and reindex.

Edit3: That fixed it. Is there any reason it keeps hanging blocks ending with multiple nines?

 

[moli]

Once again, i find the preponderance of terminal nines interesting. Is this just a coincidence?

Ref. my previous post copied below...

No they're not coincidences. Check the next blocks after those blocks where the wallets get stuck at.

85250 pays to the multisig address that i mentioned a few pages up:
http://test.insight.dash.siampm.com...eb1036cf9a4ce610b456be248e1d72e4272ab1fe31cb7

85200 pays to the same address:
http://test.insight.dash.siampm.com...f87c90fc32d3e308da287872c53451bf19edcae45ca04

85000 same thing:
http://test.insight.dash.siampm.com...4a036a3bc2cada2a980088f9ffa6eddfef8c136f1b977

 

[bertlebbert]

A couple of hrs ago I did a start-many on MNs that have no live daemon (according to scratchy anyway)... Lol, they're getting paid:

 

[eduffield]

NEW Version : V0.12.0.21

** Compiling, should be done in about 30 minutes **

Eduffield
- version bump
- Small syncing improvement
- Resync on sleep/wake or failure
- Only ask for missing masternodes/budget items after sync is complete
- Set fValid=true when receiving new votes
- Added more information to getvotes
- Budget Improvements …

UdjinM6
- revert all changes regarding attempts to lower fee
- more checks on MN register
- Slightly refactor masternode statuses: …
- Budget module refactor …
- Few sync improvements: …

Linux32:
https://dashpay.atlassian.net/build...n-linux-dash-dist//dash-0.12.0-linux32.tar.gz

Linux64:
https://dashpay.atlassian.net/build...n-linux-dash-dist//dash-0.12.0-linux64.tar.gz

Mac:
https://dashpay.atlassian.net/build...n-osx-dash-dist//dash-0.12.0-osx-unsigned.dmg

Win32:
https://dashpay.atlassian.net/build...1/gitian-win-dash-dist//dash-0.12.0-win32.zip

Win64:
https://dashpay.atlassian.net/build...1/gitian-win-dash-dist//dash-0.12.0-win64.zip

 

[bertlebbert]

NEW Version : V0.12.0.21

** Compiling, should be done in about 30 minutes **

Eduffield
- version bump
- Small syncing improvement
- Resync on sleep/wake or failure
- Only ask for missing masternodes/budget items after sync is complete
- Set fValid=true when receiving new votes
- Added more information to getvotes
- Budget Improvements …

UdjinM6
- revert all changes regarding attempts to lower fee
- more checks on MN register
- Slightly refactor masternode statuses: …
- Budget module refactor …
- Few sync improvements: …

Linux32:
https://dashpay.atlassian.net/build...n-linux-dash-dist//dash-0.12.0-linux32.tar.gz

Linux64:
https://dashpay.atlassian.net/build...n-linux-dash-dist//dash-0.12.0-linux64.tar.gz

Mac:
https://dashpay.atlassian.net/build...n-osx-dash-dist//dash-0.12.0-osx-unsigned.dmg

Win32:
https://dashpay.atlassian.net/build...1/gitian-win-dash-dist//dash-0.12.0-win32.zip

Win64:
https://dashpay.atlassian.net/build...1/gitian-win-dash-dist//dash-0.12.0-win64.zip

Perfect! start-many produces proper result trying to connect to "expired" IPs:

"status" : {
"alias" : "MN_24",
"result" : "failed",
"errorMessage" : "Error: Could not connect to 188.165.84.226:19999"
}

Get the same result for all 24 dead nodes. It does take a while; but hey, Good is better than Quick.

 

[moli]

Perfect! start-many produces proper result trying to connect to "expired" IPs:

"status" : {
"alias" : "MN_24",
"result" : "failed",
"errorMessage" : "Error: Could not connect to 188.165.84.226:19999"
}

Get the same result for all 24 dead nodes. It does take a while; but hey, Good is better than Quick.

This doesn't mean it solves the dropping issue on scratchy's server though? Because scratchy still has to figure out why the nodes get dropped from his server?

 

[bertlebbert]

This doesn't mean it solves the dropping issue on scratchy's server though? Because scratchy still has to figure out why the nodes get dropped from his server?

Yep, I guess he'll have to figure that out.

 

[bertlebbert]

Perfect! start-many produces proper result trying to connect to "expired" IPs:

"status" : {
"alias" : "MN_24",
"result" : "failed",
"errorMessage" : "Error: Could not connect to 188.165.84.226:19999"
}

Get the same result for all 24 dead nodes. It does take a while; but hey, Good is better than Quick.

Also, results from "masternodelist full" command seem to be correct.

 

[TanteStefana]

I'm trying to check on my masternode status v21, and instead of "masternode started successfully" I got this:

}
root@Beverkenverlt:~# dash-cli masternode debug
No problems were found
root@Beverkenverlt:~# dash-cli masternode status
{
"vin" : "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
"service" : "[::]:0",
"status" : 0,
"pubKeyMasternode" : "yFhRuJmX6oYYcYamMqnRq61Qd2x5aQW8Kf",
"notCapableReason" : ""
}

I don't understand the information under masternode status, it says status 0

is my masternode not started?

I just issued a masternode start, and now it says "masternode successfully started" whereas it used to simply be on before.

 

[moocowmoo]

I don't understand the information under masternode status, it says status 0

is my masternode not started?

Yes, you hadn't started it. Here's the codes from masternode.h

16 #define MASTERNODE_INITIAL                     0 // initial state
17 #define MASTERNODE_SYNC_IN_PROCESS             1
18 #define MASTERNODE_INPUT_TOO_NEW               2
19 #define MASTERNODE_NOT_CAPABLE                 3
20 #define MASTERNODE_STARTED                     4

And now that it's started, you should get 'masternode successfully started' from debug and 4 from status.

 

[TanteStefana]

Ok, I almost always saw "not capable... or " successfully started, and lately, it just automatically started up when I started the wallet up, which I thought was a new feature. So I posted the quirk ;P Thanks