Voter: This is the person who is allowed to vote on behalf the masternode. He cannot modify any of the masternode metadata.<\/li>\n<\/ol>\nThe three roles are internally differentiated by the associated public keys, which are specified in the registration transaction. If all keys are set to the same, it means that the owner is also the operator and voter. If different keys are used, it implies delegation of roles to other keys and\/or people. If any key is unassigned (zero), the transaction is invalid.<\/p>\n
Collateral and\u00a0rewards<\/h3>\n The registration transaction will also be the collateral, meaning that one of its outputs will contain the 1000 Dash. If this output is spent (collateral moved), the masternode is removed from the masternode list. The collateral address can be a P2PKH (pay-to-public-key-hash) or a P2SH (pay-to-script-hash) address in the new system.<\/p>\n
The limitation that the masternode rewards can only be paid to the same address as the collateral address is lifted by including a reward payment address in the registration transactions metadata. The reward address can also be a P2SH addresses in the new system.<\/p>\n
The owner can also specify the percentage of the masternode rewards that he wants to give to the operator. This value can only be set once when the masternode is registered and thus needs to be negotiated in advance. To claim the operator reward, the operator has to specify his reward payment address when he updates the operational masternode information.<\/p>\n
Updating Masternode IP<\/h3>\n The IP is considered to be operational information. Only the operator can change it and he can do so without the owners approval or help.<\/p>\n
The IP is initially set in the registration transaction, but can also be omitted when registering the masternode. If omitted, an update from the operator is required to fully enable the masternode. This should reduce the required communication between the owner and operator and also reduce the number of mistakes the owner can make.<\/p>\n
SPV clients and masternodes<\/h3>\n In the current\/old system, SPV clients are not able to verify the masternode list. The reason for this is that they would need to verify the collateral UTXO of each masternode, which can only be done on the full chain. Also, the network traffic required to to keep the masternode list up-to-date is not very mobile friendly.<\/p>\n
With DIP4, we introduce a way for SPV clients to retrieve and verify the full masternode list. This is basically done by committing a new merkle root hash to the coinbase transaction, which can then be used by the SPV client to verify the list.<\/p>\n
This change will have some nice effects in the Dash ecosystem. It will allow SPV clients (including mobile clients) to use advanced Dash features like PrivateSend and receival\/verification of InstantSend (sending does not require the masternode list). It is also the basis for future, Evolution related features on SPV clients.<\/p>\n
PoSe (Proof-of-Service) banned masternodes<\/h3>\n DIP3 introduces the concept of \u201cPoSe-banned\u201d masternodes. These are masternodes which failed some PoSe verification and are thus removed from the valid masternode subset. The DIPs for PoSe-verification are not fully finished yet and we plan to publish them separately.<\/p>\n
Interface to the new\u00a0system<\/h3>\n The new system will require a set of new RPC commands to create and update the deterministic masternodes. We will describe the new interface in a separate blog post and also update the necessary documentation for this later.<\/p>\n
Additionally, we will move all key handling related to masternodes into the wallet. This means that it won\u2019t be necessary to manually edit\/update the \u201cmasternode.conf\u201d file anymore.<\/p>\n
Special Transactions<\/h3>\n DIP2 introduces a new transaction version. The new version enables the addition of well-defined payloads to transactions and forms the basis for the other DIPs introduced in this post. It will also be the basis for many other features which are currently being designed and developed.<\/p>\n
State of the\u00a0DIPs<\/h3>\n The DIPs are meant to be proposals and open for discussion. We ask the community and Dash Core members to review and comment on these. If any changes to the DIPs are needed, we will integrate these.<\/p>\n
There are also other DIPs in various stages of research, design, and development which might require changes to the already published DIPs. It is currently unknown how future DIPs will affect the already published DIPs.<\/p>\n
Implementation<\/h3>\n The implementation of the deterministic masternodes system is already underway. Dash Core developers have reached a point where DIP2, DIP3 and DIP4 have been implemented and tested. This functionality is already running in a stable state in one of our devnets. Pull requests will be released\/created soon.<\/p>\n
Deployment<\/h3>\n The introduction of the deterministic masternodes system requires a multi-stage deployment and changes in many parts of the Dash ecosystem. We have worked out a deployment plan that has been tested multiple times (thanks to devnets). We will publish another blog post with the detailed deployment plan.<\/p>\n","protected":false},"excerpt":{"rendered":"
Introducing Deterministic Masternode Lists<\/h1>\r\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":"","_links_to":"","_links_to_target":""},"categories":[290],"tags":[225,220,271,223],"acf":[],"yoast_head":"\nIntroducing Deterministic Masternode Lists - Dash<\/title>\n \n \n \n \n \n \n \n \n \n \n \n \n\t \n\t \n\t \n \n \n \n \n \n\t \n\t \n\t \n