Owner vs. Operator etc.

Sven

Sven

Member
I'm not really clear about some of the concepts of the new masternode setup. First, what is the difference between owner and operator? Perhaps that also helps clear up what operatorReward is for. I'd put 100% in there because of course I want all of it. But if not, where else would it go?

Also, at https://docs.dash.org/en/stable/masternodes/dip3-upgrade.html#dashcore-dip3-upgrade it shows how to construct the ProRegTx and it says:

ownerKeyAddr: The new Dash address generated above for the owner/voting address
votingKeyAddr: The new Dash address generated above, or the address of a delegate, used for proposal voting

Again, what's the difference? Both seem to be voting addresses.

And can I put the same payout address that I've been using before?
 
Sven said:
I'm not really clear about some of the concepts of the new masternode setup. First, what is the difference between owner and operator? Perhaps that also helps clear up what operatorReward is for. I'd put 100% in there because of course I want all of it. But if not, where else would it go?

Also, at https://docs.dash.org/en/stable/masternodes/dip3-upgrade.html#dashcore-dip3-upgrade it shows how to construct the ProRegTx and it says:

ownerKeyAddr: The new Dash address generated above for the owner/voting address
votingKeyAddr: The new Dash address generated above, or the address of a delegate, used for proposal voting

Again, what's the difference? Both seem to be voting addresses.

And can I put the same payout address that I've been using before?
Click to expand...

If you have full control over your masternode and handle all the VPS stuff yourself too then you are basicly an owner + operator + voter.

You should then only create 1 new address that is both the ownerKeyAddr & votingKeyAddr (same address).
If you receive your payments directly from your masternode, you can set operatorReward to 0 and have your full mn payment received at your payout address.
(the operatorReward % is only used if you delegate the operator task to someone else, if thats not the case you can keep it at 0).

Note : your mn payments will still go to your payoutaddress even if you set operatorReward to 100. This is because the operator needs to set its own percentage through a seperate operator command
and if that does not happen, it will just go to your payout address.

The payout address by the way can be your old mn pub key address or a new hardware address or an exchange address.

If the payout address is an address not directly under control of your wallet (hardware wallet or exchange wallet for example), you should also use the feeSourceAddress (a new address or existing address)
and make sure you have some small funds in there for the transaction fee..
 
Last edited:
Thanks, @qwizzie that helps!

@strophy, yes, I read that page. It doesn't explain the difference between the two roles very well though. Can you give an example of owner and operator being two different entities? (Something like Crowdnode? But with those fractional "ownerships", isn't Crowdnode still both owner and operator as far as the network is concerned?)

And if votingKeyAddr is used for voting, what is ownerKeyAddr used for? https://docs.dash.org/en/stable/masternodes/dip3-upgrade.html#dashcore-dip3-upgrade says it's "the owner/voting address", which seems redundant. But https://docs.dash.org/en/stable/masternodes/understanding.html#dip003-masternode-changes says it's the "address to issue ProUpRegTx transactions". I understand they can be the same as per @qwizzie above, but when would they be different? And if they are different, what would ownerKeyAddr be used for?
 
Last edited:
An example of the owner and operator being different would be someone in possession of the full 1000 Dash collateral with a limited understanding of Linux and the technical steps necessary to set up a masternode. In that case they might pay a service provider like AllNodes or moocowmoo to operate the masternode for them (operator privkey), while still retaining control of the collateral (collateral privkey, probably on a hardware wallet or cold wallet) and ownership (owner privkey). The separation of the owner and collateral key increases security because the collateral wallet does not ever need to go online. You can make any change to settings relevant to the owner (e.g. who is the operator, where you get your payouts sent, which percentage of the payout goes to the operator) using only the owner key. This is much safer because, as opposed to the collateral key, the owner key holds no balance. In turn, the operator can make changes relevant to them (where their payouts are sent, what is the IP address of the masternode, running a ProUpServTx if accidentally PoSe banned) using only the operator privkey.

For technical reasons, the owner and voter key must be identical before Spork 15 is enabled. After it is enabled, you will be able to use the owner privkey to create a ProUpRegTx and specify a different voting address. In this way, you can use a single voting privkey to vote with multiple masternodes, or delegate all your votes to someone else, such as a candidate who promises to vote on your behalf according to certain principles.

https://docs.dash.org/en/stable/masternodes/maintenance.html#updating-masternode-information

Does this help? Happy to chat more or answer further questions, glad to see MNO engaging with all this new functionality!
 
strophy said:
An example of the owner and operator being different would be someone in possession of the full 1000 Dash collateral with a limited understanding of Linux and the technical steps necessary to set up a masternode. In that case they might pay a service provider like AllNodes or moocowmoo to operate the masternode for them (operator privkey), while still retaining control of the collateral (collateral privkey, probably on a hardware wallet or cold wallet) and ownership (owner privkey). The separation of the owner and collateral key increases security because the collateral wallet does not ever need to go online. You can make any change to settings relevant to the owner (e.g. who is the operator, where you get your payouts sent, which percentage of the payout goes to the operator) using only the owner key. This is much safer because, as opposed to the collateral key, the owner key holds no balance. In turn, the operator can make changes relevant to them (where their payouts are sent, what is the IP address of the masternode, running a ProUpServTx if accidentally PoSe banned) using only the operator privkey.

For technical reasons, the owner and voter key must be identical before Spork 15 is enabled. After it is enabled, you will be able to use the owner privkey to create a ProUpRegTx and specify a different voting address. In this way, you can use a single voting privkey to vote with multiple masternodes, or delegate all your votes to someone else, such as a candidate who promises to vote on your behalf according to certain principles.

https://docs.dash.org/en/stable/masternodes/maintenance.html#updating-masternode-information

Does this help? Happy to chat more or answer further questions, glad to see MNO engaging with all this new functionality!
Click to expand...

Can you tell me more about the owner key ? All we did at this point is creating a new address which we called the ownerKeyAddr
Are we not missing steps in the upgrade guide to extract the privkey from this new address and use it for owner and voting purposes ?
Or are you saving that part of the procedure (exporting priv keys) till after spork 15 activates ?

I think after spork 15 activates masternode owners will need specific instructions or a specific guide on how to use that owner address exactly (how to export their privkey)
and how to create a new voting address (through ProUpRegTx) and how to use that new voting address (export priv key).

Or we end up with a lot of questions (like this one : https://www.dash.org/forum/threads/dash-core-v0-13-on-mainnet.43130/page-2#post-207307)
 
Last edited:
In general, it should never be necessary to play around with privkeys. They can (and should) remain safely in wallet files, protected by passphrases. All transactions should be handled through the console (e.g. vote-many). If delegating to another user's wallet, the delegee should send you his public voting address rather than you sending him your voting privkey. It's the same as a transaction - when you want to send someone Dash, you create a transaction rather than sending an address privkey by email or whatever in the clear. These functions relating to masternode control using keys and addresses should be thought of in the same way: you should create a protx to achieve the desired function instead of sending around privkeys.

The functions are described in detail here:
https://docs.dash.org/en/stable/masternodes/maintenance.html#updating-masternode-information
 
strophy said:
In general, it should never be necessary to play around with privkeys. They can (and should) remain safely in wallet files, protected by passphrases. All transactions should be handled through the console (e.g. vote-many). If delegating to another user's wallet, the delegee should send you his public voting address rather than you sending him your voting privkey. It's the same as a transaction - when you want to send someone Dash, you create a transaction rather than sending an address privkey by email or whatever in the clear. These functions relating to masternode control using keys and addresses should be thought of in the same way: you should create a protx to achieve the desired function instead of sending around privkeys.

The functions are described in detail here:
https://docs.dash.org/en/stable/masternodes/maintenance.html#updating-masternode-information
Click to expand...

Wont Dash Central or Dash Nexus need a voting priv key though ? We gave Dash Central our masternode privkey in the past too right ? Or is providing them with the public voting adress gonna be enough ? (btw : what happens with our old masternode priv key after activation of spork 15 ? will it get obsolete?)
If we are not suppose to play around with privkeys, then why is it explicitly mentioned here : "For technical reasons, the owner and voter key must be identical before Spork 15 is enabled. After it is enabled, you will be able to use the owner privkey to create a ProUpRegTx and specify a different voting address. In this way, you can use a single voting privkey to vote with multiple masternodes"

I'm seeing referrals to privkeys left and right, while all i have is a new (public) address thats used for owner address and voting address. Makes it all a bit confusing.
 
Last edited:
Fair enough, I did throw the word privkey around a lot ;) I was just trying to be unambiguous when referring to the keys. In practice, when you create a ProUpRegTx, you don't even specify the owner privkey or pubkey in the transaction - it is implied by the proTxHash which the transaction references. The transaction can only be successfully created if the owner address (i.e. privkey and pubkey) are in the wallet creating the transaction. What happens in the background is Dash Core looks up the masternode on the blockchain by its registration txid (proTxHash) and immediately knows the current configuration, very much in the same way that it can look up an address and immediately know its balance. From this information, it therefore knows the owner pubkey, and can check if the privkey is present in the currently open wallet. It then uses that privkey to create the ProUpRegTx as specified by the owner, and as soon as it is mined to a block, all other nodes immediately know about and can validate the change in configuration was legitimate and intended by the owner. It really works exactly like a monetary transaction, except in this case we are transacting an information payload to a distributed consensus network.

I'm not sure how Central/Nexus plan to implement voting through their interface. In the past, yes, you gave them the masternode privkey (encrypted and decrypted client-side using JS). Under DIP3 you could also give them the privkey or, as I described in my past two posts, they could specify a pubkey to which they control the privkey. You then create a ProUpRegTx in your wallet nominating this pubkey as the voting delegate. In this way, without ever exposing privkeys, you can now vote using their interface. This could be done on a per-masternode or per-user-account basis. Cool!

After Spork 15 is activated, the old masternodeprivkey is no longer used for network functions. However, it must still be present in the dash.conf file due to a legacy check which had to remain in the 0.13.x codebase to ensure masternodes could continue functioning in compatibility mode during this transition phase. Because this check is carried out during startup, a dummy masternodeprivkey must also be present when starting a "clean" node using only the DIP3 registration process, even after Spork 15 has activated. This check (and a ton of other legacy code) will most likely be removed in the 0.14 release. I've seen the commit and it literally deletes thousands of lines of code related to the old P2P masternode messages. It's a big cleanup :)
 
Very helpful. Thank you!

I appreciate you typing this all out for us and I imagine others may have similar questions. This should be incorporated into the documentation, perhaps fleshed out a bit with examples.
 
You must log in or register to reply here.
Back
Top