IP switching MNs when the die...

[camosoul]

I'm not sure how to phrase this, so I'll just blab on a bit.

When an MN "fails" in some way...

We know that the IP gets associated with the mnprivkey and 1000drk pubkey.

Try to restart a new MN with the same IP, but different mnprivkey and 1000drk pubkey == it doesn't wanna. Mismatch of the "registered" IP/masternodeprivkey/1000drk pubkey

vultr lets you kill the vm, install a new one, and you get a new IP every time you do that. So, no need to worry about being associated with the old IP cuz you're not using it.

But what about VPSes that retain the IP? There are some pretty good annual deals on lowendbox.com, but they have some limitations, such as always sticking witht he same IP address no matter how many times you destroy/re-create the VPS.

Is there a timeframe after which the MN network will lose the IP associations and I'd be free to restart an MN on the same old IP, but with new masternodeprivkey and 1000drk pubkey?

 

[thelonecrouton]

Rebuilt all my MNs on Sunday or Monday I think, reused the same IPs for all of them, just a fresh DRK address and a fresh masternodeprivkey. No issues. Up and listed straight away. All subsequently paid within expected schedule.

edit: did it due to the disappearing-after-60mins MN bug, they had all been offline overnight prior to reconstruction.

 

[UdjinM6]

I'm not sure how to phrase this, so I'll just blab on a bit.

When an MN "fails" in some way...

We know that the IP gets associated with the mnprivkey and 1000drk pubkey.

Try to restart a new MN with the same IP, but different mnprivkey and 1000drk pubkey == it doesn't wanna. Mismatch of the "registered" IP/masternodeprivkey/1000drk pubkey

vultr lets you kill the vm, install a new one, and you get a new IP every time you do that. So, no need to worry about being associated with the old IP cuz you're not using it.

But what about VPSes that retain the IP? There are some pretty good annual deals on lowendbox.com, but they have some limitations, such as always sticking witht he same IP address no matter how many times you destroy/re-create the VPS.

Is there a timeframe after which the MN network will lose the IP associations and I'd be free to restart an MN on the same old IP, but with new masternodeprivkey and 1000drk pubkey?

Did you issue "masternode stop" first? That should propagate message to network to remove you from masternode list so you can safely start new later.
Make sure you have new masternodeprivkey in both local and remote configs.

 

[camosoul]

Did you issue "masternode stop" first? That should propagate message to network to remove you from masternode list so you can safely start new later.
Make sure you have new masternodeprivkey in both local and remote configs.

I didn't do anything ... yet. I'm enquiring as to proper procedure.

they had all been offline overnight prior to reconstruction.

I'd rather not take that long.

Seems the network can be told to drop it, so, this way cheaper VPS I'm considering might be workable.

 

[camosoul]

So, I gather I should issue "masternode stop" and this will remove the association records from the network almost immediately?

Get a new MNprivkey and also move all the DRKs to new addresses is something I already presumed would be necessarry. Can I skip the sending to new pubkey and keep using the same pubkey over and over?

Just don't want to get caught in any undocumented stuffs + ping bug again... ;-)

So, I can just change the mnprivkey, and leave everything else the same; so long as the records have been completely dropped by the network, and issuing "masternode stop" causes that to happen almost instantly?

 

[Ignition75]

So, I gather I should issue "masternode stop" and this will remove the association records from the network almost immediately?

Get a new MNprivkey and also move all the DRKs to new addresses is something I already presumed would be necessarry. Can I skip the sending to new pubkey and keep using the same pubkey over and over?

Just don't want to get caught in any undocumented stuffs + ping bug again... ;-)

So, I can just change the mnprivkey, and leave everything else the same; so long as the records have been completely dropped by the network, and issuing "masternode stop" causes that to happen almost instantly?

In my experience I've found the IP binding to be permanent.

The network thinks one of my Amsterdam masternodes is in Singapore, because Digital Ocean re-use their IP addresses and someone in the past must have had my IP on a Singapore node.

 

[camosoul]

In my experience I've found the IP binding to be permanent.

The network thinks one of my Amsterdam masternodes is in Singapore, because Digital Ocean re-use their IP addresses and someone in the past must have had my IP on a Singapore node.

Does hinder the function of the MN in any way?

 

[Ignition75]

Does hinder the function of the MN in any way?

No issues at all, it's working fine, I wish all my masternodes had misintended geographical obfuscation :wink:

 

[UdjinM6]

So, I gather I should issue "masternode stop" and this will remove the association records from the network almost immediately?

Get a new MNprivkey and also move all the DRKs to new addresses is something I already presumed would be necessarry. Can I skip the sending to new pubkey and keep using the same pubkey over and over?

Just don't want to get caught in any undocumented stuffs + ping bug again... ;-)

So, I can just change the mnprivkey, and leave everything else the same; so long as the records have been completely dropped by the network, and issuing "masternode stop" causes that to happen almost instantly?

Yes, you don't have to move your funds. Once stop message propagates there will be no record in masternode list of "old" vin/pubkey and you can use it to start masternode with new masternodeprivekey. And "masternode stop" uses the same messaging way to propagate as "masternode start" so message should arrive almost instantly BUT looking into code I must say that inactive masternodes are removed only once in a minute and that particular masternode finally stops only when it tries to send dseep ping to network (??) so give it at least 5 minutes to complete.
(that sounds strange, I know, need to have closer look at this)
It looks like you can speed up this by issuing "masternode stop" on remote too but I didn't try it by myself so I would suggest just to wait 5 minutes instead.

To summarize - steps to start with new masternodeprivkey should be something like that:
- issue "masternode stop passphrase" from local wallet - this should give you "masternode is stopped"
- close your local wallet
- make sure your masternode is delisted (or at least that stop message reached your masternode) - issue "darkcoind masternode list | grep YOUR_IP" on remode node - you should get empty result
- make sure your masternode is stopped - issue "darkcoind masternode debug" on remote node - this should give you "masternode is stopped"
- stop remote daemon
- change masternodeprivkey in both local and remote configs
- start remote daemon
- start local wallet and issue "masternode start passphrase" from it

Hopefully you will have your new masternode up and running with new masternodeprivkey and old vin/pubkey :smile:

 

[camosoul]

Yes, you don't have to move your funds. Once stop message propagates there will be no record in masternode list of "old" vin/pubkey and you can use it to start masternode with new masternodeprivekey. And "masternode stop" uses the same messaging way to propagate as "masternode start" so message should arrive almost instantly BUT looking into code I must say that inactive masternodes are removed only once in a minute and that particular masternode finally stops only when it tries to send dseep ping to network (??) so give it at least 5 minutes to complete.
(that sounds strange, I know, need to have closer look at this)
It looks like you can speed up this by issuing "masternode stop" on remote too but I didn't try it by myself so I would suggest just to wait 5 minutes instead.

To summarize - steps to start with new masternodeprivkey should be something like that:
- issue "masternode stop passphrase" from local wallet - this should give you "masternode is stopped"
- close your local wallet
- make sure your masternode is delisted (or at least that stop message reached your masternode) - issue "darkcoind masternode list | grep YOUR_IP" on remode node - you should get empty result
- make sure your masternode is stopped - issue "darkcoind masternode debug" on remote node - this should give you "masternode is stopped"
- stop remote daemon
- change masternodeprivkey in both local and remote configs
- start remote daemon
- start local wallet and issue "masternode start passphrase" from it

Hopefully you will have your new masternode up and running with new masternodeprivkey and old vin/pubkey :smile:

Since I'm using start-many, I think issuing the "masternode stop" from the remote only should do the job. I can monitor "masternode list | grep remoteip" on the local and/or elbereth's magnificent expreg thing for delisting. Local issuance of "masternode start" is just a one-time announcement. The remotes are what have to ping to keep alive, so it makes sense to shut them down that way. The local client shouldn't be able to hold them on the network since it isn't pinging.

Then I can just start over with new mnprivkey with fresh VPS image. Match IP to new mnprivkey in local masternode.conf, and startup like normal with start-many.

Always a good idea to give the network some time to catch lag. I'd probably wait 2 hours, not 5 minutes. When there's a major update requiring this sort of restart/rebuild, it takes a few days just to reach 50% protocol version compliance anyway... 2 hours might be overkill, but it doesn't hurt anything, either, and is beyond the 70 minute natural decay, so that would work for me, too, now that drift is fixed.

Or course, everybody races when the count is low, hunting those payments...

I also found that going:

1) ./darkcoind on remote (node is pre-heated with full blockchain prior to this)
2) masternode start-many
3) wait 2 minutes
4) ./darkcoind masternode start on remote machines all a the same time

Pretty much guarantees they'll work, no problem.

Instead of greping the masternode list, it's easier to just create the string for elbereth's site out of the local wallet's pubkeys. Can do this in advance of issuing the start-many for convenience and time-saving at the moment of issuing the start-many.

This masternode stuff is nowhere near as complicated or difficult as the "guides" try to make it sound... These guides people want to make themselves look cool so they blow it way, way out of proportion so they can appear like a hero of this impossible task they've made it out to be... I don't even have anything written down. It's just common sense once you have the facts that are conveniently not mentioned in the guides... Don't even have to think about it... It's just not a big deal. Evan did all the work.

 

[camosoul]

Moved my nodes to a host much, much cheaper than vultr. All went according to plan. No problems. It just works.

I've never done an MN any way other than start-many. Would love to see this feature grow to:

"masternode start mnprivkey/pubkey"
"masternode stop mnprivkey/pubkey"
"masternode start-all"
"masternode stop-all"

Making it keep track of VIN associations would enable everything here. Doesn't look like it would be that hard... Leave the masternode.conf on it's own, let the program append the VIN association to the end of the line for each one upon issuance of a start command (be it "start-all" or "start mnprivkey" per above), no room for human error in the association that way...

Looks like UdjinM6 is the bagholder on that ticket...

Of course this neglects that other undocumented feature where a single 9000 can hold 9 nodes without having to break it up into 9x 1000... Don't know if they can co-exist, or one will have to be chosen over another. Might make more sense to lock a given amount with total disregard to the addresses it sits on, and just dole out the increments... Pubkeys where the payments go, meh...

 

[oblox]

Moved my nodes to a host much, much cheaper than vultr. All went according to plan. No problems. It just works.

TragicServers? I was eyeing them up as well (assuming this is who you moved to) due to how many are now on Vultr.

 

[UdjinM6]

Moved my nodes to a host much, much cheaper than vultr. All went according to plan. No problems. It just works.

I've never done an MN any way other than start-many. Would love to see this feature grow to:

"masternode start mnprivkey/pubkey"
"masternode stop mnprivkey/pubkey"
"masternode start-all"
"masternode stop-all"

Making it keep track of VIN associations would enable everything here. Doesn't look like it would be that hard... Leave the masternode.conf on it's own, let the program append the VIN association to the end of the line for each one upon issuance of a start command (be it "start-all" or "start mnprivkey" per above), no room for human error in the association that way...

Looks like UdjinM6 is the bagholder on that ticket...

Of course this neglects that other undocumented feature where a single 9000 can hold 9 nodes without having to break it up into 9x 1000... Don't know if they can co-exist, or one will have to be chosen over another. Might make more sense to lock a given amount with total disregard to the addresses it sits on, and just dole out the increments... Pubkeys where the payments go, meh...

Thanks for suggestions, added to JIRA to keep track of it
http://jira.darkcoin.qa/browse/DRK-...issuetabpanels:comment-tabpanel#comment-10513

 

[camosoul]

Of course this neglects that other undocumented feature where a single 9000 can hold 9 nodes without having to break it up into 9x 1000... Don't know if they can co-exist, or one will have to be chosen over another. Might make more sense to lock a given amount with total disregard to the addresses it sits on, and just dole out the increments... Pubkeys where the payments go, meh...

I was all wet about that. Scratch that as bunk and plops.

if you fund more than 1 masternode in the same transaction, all payments will go to the first address and none to the rest. It makes it really easy to keep track of how much you're making. This person funded 10 at once: http://explorer.darkcoin.fr/block/00000000001226eaed26fc9a551f09da32fa944503f671782afb706e9225be6f

So, the nodes all paying to one is related to how one chooses to handle the blockchain and should operate transparently/parallel to multi-MN handling in the client.