search

dashpay / dash

Dash - Reinventing Cryptocurrency
https://www.dash.org
MIT License
1.49k stars 1.2k forks source link

Masternode-Update #539

Closed scratchy closed 9 years ago

scratchy commented 9 years ago

Hey,

As I noticed currently theres a need of resending the Masternode 'start' command on version bump. I guess the reason for this, that new pings after version bumps are rejected. It would be awesome if its possible to upgrade masternodes without resending the start command, is there any possibility / anything planed?

UdjinM6 commented 9 years ago

Protocol version is a critical parameter and it's included in signed mnb message that is sent on masternode start/-many/alias. You have to sign another message when there is a proto bump, and you can only sign it with collateral's 1000 DASH private key.

So no, not going to be implemented imo.

scratchy commented 9 years ago

Sad to hear that.

I dont get why the protocol number is that critical, that it has to be signed? Its pretty hard to keep the nodes updated like this. The reason for this is there a lot of "hosting-services" out there (including one im running) which dont own the private key for the nodes. Now there are two possiblitys if theres a version bump:

  1. Update the nodes (thats what should be the best solution), but then ALL nodes will drop from the Masternode-List, because the hosters cant resend the start command.
  2. Dont update the nodes as long as its enforced, thats sadly currently the best solution for the Masternode owners but not for the Dash-Network (Running on old versions should not be the best solution, should it?). The reason why its currently preffered is because the nodes are online as much time as possible but after the enforcement, all nodes will drop again waiting for the owners to resend the start command, so were here on the same issue.

Both solutions are not optimal, because they lead to a downtime of Masternodes (as long as all users resend their mnb), which in fact is bad for the network and for the hosting services. Im up to solutions for updating masternodes or other idears how to update the nodes without downtime, but as far as i can see it, its not possible without help on the dashd side. Imo there should be a 'transport' of the masternode list between version bumps. This could be possible by flagging transported nodes, (maybe a second list?) and time them out after 1 week or something like that.

And the sad story about it, its not one update / year or something like that.. theres a lot of version bumps which disconnect the nodes really often. At least if your goal is to use the lastes protocol version (which should everyones goal).

UdjinM6 commented 9 years ago

I hear what you're saying but MN network wasn't made to be a simple runonce&forget POStake-like earning model, it was made to provide services for the majority of users and MN owners/operators should care about if their MNs actually doing this job. And we (users/network) need a way to confirm this at least with some point of assurance.

But maybe there's a 3rd solution:

  1. MN-hosting service should give Masternode owners a way (special api key, for example) for upgrading/restarting their nodes from their own web page (or app etc.) so that every client could monitor and manage his own MNs by himself in an easy way letting the hoster to handle hardware/scripting stuffs.

Note: protocol bumps happen only on major updates when payments enforcement is off and no one will be dropped out of the payments queue because of the upgrade.