joshua/dips
1
0
Fork 0
mirror of https://github.com/seigler/dips synced 2025-07-27 09:46:12 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Clarify word choice (#17)

Browse source 
DIP-3 updated
This commit is contained in:
Kamuela Franco 2018-10-01 14:19:28 +01:00 • committed by thephez
parent 96d36a768d
commit 0d09d80194
1 changed files with 2 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

4
dip-0003.md
View file

@ -71,8 +71,8 @@ To join the masternode list, masternode owners must submit a special transaction
The ProRegTx contains 3 public key IDs, which represent 3 different roles in the masternode and define update and voting rights. A "public key ID" refers to the hash160 of an ECDSA public key. These are: The ProRegTx contains 3 public key IDs, which represent 3 different roles in the masternode and define update and voting rights. A "public key ID" refers to the hash160 of an ECDSA public key. These are:
1. KeyIdOwner: This is the public key ID of the masternode or collateral owner. It is different than the key used in the collateral output. The owner is only allowed to issue ProUpRegTx transactions. 1. KeyIdOwner: This is the public key ID of the masternode or collateral owner. It is different than the key used in the collateral output. Only the owner is allowed to issue ProUpRegTx transactions.
2. KeyIdOperator: This is the public key ID of the masternode operator. The operator is only allowed to issue ProUpServTx transactions. The operator key is also used while operating the masternode to sign masternode related P2P messages, quorum related messages and governance trigger votes. Messages signed with this key are only valid while the masternode is in the valid set. 2. KeyIdOperator: This is the public key ID of the masternode operator. Only the operator is allowed to issue ProUpServTx transactions. The operator key is also used while operating the masternode to sign masternode related P2P messages, quorum related messages and governance trigger votes. Messages signed with this key are only valid while the masternode is in the valid set.
3. KeyIdVoting: This is the public key ID used for proposal voting. Votes signed with this key are valid while the masternode is in the registered set. 3. KeyIdVoting: This is the public key ID used for proposal voting. Votes signed with this key are valid while the masternode is in the registered set.
A single key can be used for multiple roles so the owner can also operate the masternode and/or issue proposal votes. Alternately, different keys can be used to delegate duties to other people. For example, owners might decide to use a masternode hosting service instead of self-hosting the masternode. To do so, they would use the operator key provided by the hosting service. The same applies to the voting key, which allows them to assign voting rights to someone else. A single key can be used for multiple roles so the owner can also operate the masternode and/or issue proposal votes. Alternately, different keys can be used to delegate duties to other people. For example, owners might decide to use a masternode hosting service instead of self-hosting the masternode. To do so, they would use the operator key provided by the hosting service. The same applies to the voting key, which allows them to assign voting rights to someone else.