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

Merge pull request #21 from dashpay/UdjinM6-patch-1

Browse source 
Separate creation/movement of MN collateral and DMN registration process
This commit is contained in:
Alexander Block 2018-10-24 13:07:49 +02:00 • committed by GitHub
commit d65b356abf
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 19 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

35
dip-0003.md
View file

@ -56,7 +56,7 @@ The previous system also made certain desirable features infeasible. The integra
## 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 includes either a 1000-Dash collateral payment or a reference to it, along with other payload information (DIP2) described later in this document.
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)
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 include an output with the 1000 DASH or refer to an already existing unspent output which holds 1000 DASH.
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.
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.
@ -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. |
| type | uint_16 | 2 | Masternode type. 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) |
| port | uint_16 | 2 | Port (network byte order) |
| 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) |
| inputsHash | uint256 | 32 | Hash of all the outpoints of the transaction inputs |
| 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 in case the collateral is not part of the ProRegTx itself, empty otherwise. |
## Updating Masternode Information
@ -211,17 +211,20 @@ Reorganisations of the chain must also correctly undo changes to the chain-tips
A ProRegTx is invalid if any of these conditions are true:
1. collateralIndex >= transaction output count
2. Any KeyId* field is null (KeyIdOwner, KeyIdOperator or KeyIdVoting)
3. KeyIdOwner or KeyIdOperator was already used by any entry in the registered masternodes set
4. scriptPayout is not a P2PKH or P2SH script
5. When scriptPayout is P2PKH script and the public key hash equals any of KeyIdOwner, KeyIdOperator or KeyIdVoting
6. ipAddress is set and port is not set to the default mainnet port
7. ipAddress is set and not routable or not an IPv4 mapped address
8. ipAddress is set and already used in the registered masternodes set
9. operatorReward > 10000
10. The inputsHash does not match the calculated hash
11. payloadSig is invalid
1. collateralOutpoint `hash` is null but an output with 1000 DASH is not present at position `n` of the ProRegTx outputs
2. collateralOutpoint `hash` is not null but an output with 1000 DASH can't be found in the UTXO specified by the `hash` and `n`
3. Any KeyId* field is null (KeyIdOwner, KeyIdOperator or KeyIdVoting)
4. KeyIdOwner or KeyIdOperator was already used by any entry in the registered masternodes set
5. scriptPayout is not a P2PKH or P2SH script
6. When scriptPayout is P2PKH script and the public key hash equals any of KeyIdOwner, KeyIdOperator or KeyIdVoting
7. ipAddress is set and port is not set to the default mainnet port
8. ipAddress is set and not routable or not an IPv4 mapped address
9. ipAddress is set and already used in the registered masternodes set
10. operatorReward > 10000
11. The inputsHash does not match the calculated hash
12. collateralOutpoint `hash` is null and payloadSig is not empty (zero size)
13. collateralOutpoint `hash` is not null and payloadSig is not a valid signature signed with the collateral key
14. collateralOutpoint `hash` is not null and the referenced collateral is not a P2PKH output
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.