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

Separate creation/movement of MN collateral and DMN registration process

Browse source 
I propose to change DIP3 in a way that splits funds handling and DMN registration.

Pros:
1. no need to move collaterals;
2. no need to update HW wallet firmware to support.

Cons:
1. the logic is going to be slightly more complicated;
2. the process of MN registration is going to be split between using HW wallet and Core;
3. `ProRegTx` payload size is going to be slightly higher (+32 bytes).
This commit is contained in:
UdjinM6 2018-10-16 05:00:05 +03:00 • committed by GitHub
parent da784d71c7
commit 0f1ce92f94
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 17 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

33
dip-0003.md
View file

@ -56,7 +56,7 @@ The previous system also made certain desirable features infeasible. The integra
## New On-Chain System ## New On-Chain System
In the new system, the masternode list is derived entirely from information found on-chain. New masternodes are added by new special transactions called Provider Registration Transactions (abbreviated as ProRegTx). They are only removed by spending the collateral. A ProRegTx is a special transaction which consists of a 1000-Dash collateral payment, along with payload information (DIP2) described later in this document. In the new system, the masternode list is derived entirely from information found on-chain. New masternodes are added by new special transactions called Provider Registration Transactions (abbreviated as ProRegTx). They are only removed by spending the collateral. A ProRegTx is a special transaction which refers to a 1000-Dash collateral payment, along with other payload information (DIP2) described later in this document.
This DIP defines 2 masternode (sub)sets: This DIP defines 2 masternode (sub)sets:
@ -67,7 +67,7 @@ Only the valid subset is used in calculations to determine the recipient of the
## Registering a Masternode (ProRegTx) ## Registering a Masternode (ProRegTx)
To join the masternode list, masternode owners must submit a special transaction (DIP2) to the network. This transaction is called a Provider Registration Transaction and is abbreviated to ProRegTx. The ProRegTx must contain one output with the 1000 Dash collateral. To join the masternode list, masternode owners must submit a special transaction (DIP2) to the network. This transaction is called a Provider Registration Transaction and is abbreviated to ProRegTx. The ProRegTx must refer to an outpoint with the 1000 Dash collateral.
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:
@ -83,7 +83,7 @@ The ProRegTx also defines the masternode's type and mode. Default masternodes ar
The ProRegTx also specifies the reward for the operator. The percentage of the masternode reward paid to the operator is calculated by dividing the operatorReward field by 100. When the field is set to zero, the owner will get the full reward for every block. If set to a non-zero value, the masternode operator may specify his operator reward payee script in a ProUpServTx. If he does not do so, the full reward goes to the masternode owner. The ProRegTx also specifies the reward for the operator. The percentage of the masternode reward paid to the operator is calculated by dividing the operatorReward field by 100. When the field is set to zero, the owner will get the full reward for every block. If set to a non-zero value, the masternode operator may specify his operator reward payee script in a ProUpServTx. If he does not do so, the full reward goes to the masternode owner.
After a ProRegTx is mined into the chain, the corresponding masternode entry is added to the registered masternode set and therefore eligible for PoSe verification, masternode rewards and quorum participation. After a ProRegTx is mined into the chain, the corresponding masternode entry is added to the registered masternode set and therefore eligible for PoSe verification, masternode rewards and quorum participation. If there is a masternode with the same collateral outpoint in the registered masternode set already, it's replaced with the newly registered one.
The special transaction type used for Provider Transactions is 1. The special transaction type used for Provider Transactions is 1.
@ -94,7 +94,7 @@ The transaction consists of the following data in the payload area:
| version | uint_16 | 2 | Provider transaction version number. Currently set to 1. | | version | uint_16 | 2 | Provider transaction version number. Currently set to 1. |
| type | uint_16 | 2 | Masternode type. Default set to 0. | | type | uint_16 | 2 | Masternode type. Default set to 0. |
| mode | uint_16 | 2 | Masternode mode. Default set to 0. | | mode | uint_16 | 2 | Masternode mode. Default set to 0. |
| collateralIndex | uint_32 | 4 | The collateral index. | | collateralOutpoint | COutpoint | 36 | The collateral outpoint. |
| ipAddress | byte[] | 16 | IPv6 address in network byte order. Only IPv4 mapped addresses are allowed (to be extended in the future) | | ipAddress | byte[] | 16 | IPv6 address in network byte order. Only IPv4 mapped addresses are allowed (to be extended in the future) |
| port | uint_16 | 2 | Port (network byte order) | | port | uint_16 | 2 | Port (network byte order) |
| KeyIdOwner | CKeyID | 20 | The public key hash used for owner related signing (ProTx updates, governance voting) | | KeyIdOwner | CKeyID | 20 | The public key hash used for owner related signing (ProTx updates, governance voting) |
@ -105,7 +105,7 @@ The transaction consists of the following data in the payload area:
| scriptPayout | Script | Variable | Payee script (p2pkh/p2sh) | | scriptPayout | Script | Variable | Payee script (p2pkh/p2sh) |
| inputsHash | uint256 | 32 | Hash of all the outpoints of the transaction inputs | | inputsHash | uint256 | 32 | Hash of all the outpoints of the transaction inputs |
| payloadSigSize | compactSize uint | 1-9 | Size of the Signature | | payloadSigSize | compactSize uint | 1-9 | Size of the Signature |
| payloadSig | vector<unsigned char> | Variable | Signature of the hash of the ProTx fields. Signed with KeyIdOwner | | payloadSig | vector<unsigned char> | Variable | Signature of the hash of the ProTx fields. Signed with the key corresponding to the collateral outpoint. |
## Updating Masternode Information ## Updating Masternode Information
@ -211,17 +211,18 @@ Reorganisations of the chain must also correctly undo changes to the chain-tips
A ProRegTx is invalid if any of these conditions are true: A ProRegTx is invalid if any of these conditions are true:
1. collateralIndex >= transaction output count 1. collateralOutpoint can't be found in UTXO
2. Any KeyId* field is null (KeyIdOwner, KeyIdOperator or KeyIdVoting) 2. collateralOutpoint amount isn't equal 1000 DASH
3. KeyIdOwner or KeyIdOperator was already used by any entry in the registered masternodes set 3. Any KeyId* field is null (KeyIdOwner, KeyIdOperator or KeyIdVoting)
4. scriptPayout is not a P2PKH or P2SH script 4. KeyIdOwner or KeyIdOperator was already used by any entry in the registered masternodes set
5. When scriptPayout is P2PKH script and the public key hash equals any of KeyIdOwner, KeyIdOperator or KeyIdVoting 5. scriptPayout is not a P2PKH or P2SH script
6. ipAddress is set and port is not set to the default mainnet port 6. When scriptPayout is P2PKH script and the public key hash equals any of KeyIdOwner, KeyIdOperator or KeyIdVoting
7. ipAddress is set and not routable or not an IPv4 mapped address 7. ipAddress is set and port is not set to the default mainnet port
8. ipAddress is set and already used in the registered masternodes set 8. ipAddress is set and not routable or not an IPv4 mapped address
9. operatorReward > 10000 9. ipAddress is set and already used in the registered masternodes set
10. The inputsHash does not match the calculated hash 10. operatorReward > 10000
11. payloadSig is invalid 11. The inputsHash does not match the calculated hash
12. payloadSig is invalid
Please note that while deploying DIP3, additional and temporary validation rules will apply. The details of these temporary rules will be described in the deployment plan. Please note that while deploying DIP3, additional and temporary validation rules will apply. The details of these temporary rules will be described in the deployment plan.