diff --git a/README.md b/README.md index 409a7eda..eefc737f 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ DIP stands for Dash Improvement Proposal. Similar to Bitcoin's [BIPs](https://github.com/bitcoin/bips/), a DIP is a design document providing information to the Dash community, or describing a new feature for Dash or its processes or environment. The DIP should provide a concise technical specification of the feature and a rationale for the feature. -Because Dash is forked from the Bitcoin codebase, many of the BIPs can be applied to Dash as well (a list of the BIPs updated to include Dash-specific details can be found in the [Dash BIPs repository](https://github.com/dashevo/bips)). The purpose of the DIPs is not to duplicate those which exist as BIPs, but to introduce protocol upgrades or feature specifications which are unique to Dash. +Because Dash is forked from the Bitcoin codebase, many of the BIPs can be applied to Dash as well (a list of the BIPs updated to include Dash-specific details can be found [here](https://github.com/dashevo/bips)). The purpose of the DIPs is not to duplicate those which exist as BIPs, but to introduce protocol upgrades or feature specifications which are unique to Dash. ## Contributions diff --git a/dip-0003.md b/dip-0003.md index a56b4916..fdeb4725 100644 --- a/dip-0003.md +++ b/dip-0003.md @@ -135,10 +135,16 @@ The transaction consists of the following data in the payload area: The different versions are: -| Version | Version Description | -|---------|------------------------------------------------------| -| 1 | PubKeyOperator is serialised using legacy BLS scheme | -| 2 | PubKeyOperator is serialised using basic BLS scheme | +| Version | Version Description | +| ------- | ------------------------------------------------------- | +| 1 | PubKeyOperator is serialised using legacy BLS scheme | +| 2 | PubKeyOperator is serialised using basic BLS scheme | +| 4 | Owner payout list as defined in [DIP-0026](dip-0026.md) | + +[DIP-0026](dip-0026.md) defines version 4 ProRegTx payloads. Version 4 replaces +the single `scriptPayoutSize` and `scriptPayout` fields with an owner payout +list while leaving the existing operator reward and operator payout mechanisms +unchanged. ## Updating Masternode Information @@ -147,7 +153,7 @@ There are multiple ways to update masternodes. The table below details the data | Update Type | Transaction | Issued by | Data updated | | ----------- | ----------- | --------- | ------------ | | Service | ProUpServTx | Operator Only | Masternode addresses | -| Registration | ProUpRegTx | Owner Only | Mode / Payout Script / Voting Key / Operator Key | +| Registration | ProUpRegTx | Owner Only | Mode / Payout Script(s) / Voting Key / Operator Key | | Operator Revocation | ProUpRevTx | Operator Only | \* No data updated / * Only used to signal the owner that a new ProUpRegTx is required | ### Updating Service Features from Operator (ProUpServTx) @@ -177,9 +183,9 @@ The transaction consists of the following data in the payload area: The different versions are: -| Version | Version Description | -|---------|------------------------------------------------------| -| 1 | payloadSig is serialised using legacy BLS scheme | +| Version | Version Description | +| ------- | ----------------------------------------------------------------------------------- | +| 1 | payloadSig is serialised using legacy BLS scheme | | 2 | payloadSig is serialised using basic BLS scheme and type is included in transaction | ### Updating Registrar of Masternode (ProUpRegTx) @@ -207,10 +213,15 @@ The transaction consists of the following data in the payload area: The different versions are: -| Version | Version Description | -|---------|------------------------------------------------------| -| 1 | PubKeyOperator is serialised using legacy BLS scheme | -| 2 | PubKeyOperator is serialised using basic BLS scheme | +| Version | Version Description | +| ------- | ------------------------------------------------------- | +| 1 | PubKeyOperator is serialised using legacy BLS scheme | +| 2 | PubKeyOperator is serialised using basic BLS scheme | +| 4 | Owner payout list as defined in [DIP-0026](dip-0026.md) | + +[DIP-0026](dip-0026.md) defines version 4 ProUpRegTx payloads. Version 4 +replaces the single `scriptPayoutSize` and `scriptPayout` fields with an owner +payout list. ### Operator Self Revoking Transaction (ProUpRevTx) @@ -234,8 +245,8 @@ The transaction consists of the following data in the payload area: The different versions are: -| Version | Version Description | -|---------|------------------------------------------------------| +| Version | Version Description | +| ------- | ------------------------------------------------ | | 1 | payloadSig is serialised using legacy BLS scheme | | 2 | payloadSig is serialised using basic BLS scheme | @@ -267,14 +278,17 @@ Reorganisations of the chain must also correctly undo changes to the chain-tips A ProRegTx is invalid if any of these conditions are true: In the case of type 0: + 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` In the case of type 1: + 1. collateralOutpoint `hash` is null but an output with 4000 DASH is not present at position `n` of the ProRegTx outputs 2. collateralOutpoint `hash` is not null but an output with 4000 DASH can't be found in the UTXO specified by the `hash` and `n` Applicable to any type: + 1. Any KeyId* field is null (KeyIdOwner, KeyIdOperator or KeyIdVoting) 2. KeyIdOwner or PubKeyOperator was already used by any entry in the registered masternodes set 3. scriptPayout is not a P2PKH or P2SH script @@ -286,6 +300,12 @@ Applicable to any type: 9. collateralOutpoint `hash` is not null and payloadSig is not a valid signature signed with the collateral key 10. collateralOutpoint `hash` is not null and the referenced collateral is not a P2PKH output +For version 4 ProRegTx and ProUpRegTx payloads, the single `scriptPayout` field +is replaced by the owner payout list defined in [DIP-0026](dip-0026.md). The +version 4 payout-list validation rules in DIP-0026 replace the `scriptPayout` +validation rules above; all other applicable DIP-0003 validation rules continue +to apply unless explicitly replaced by DIP-0026. + 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. ### ProUpServTx diff --git a/dip-0026.md b/dip-0026.md index 05ee0424..33352045 100644 --- a/dip-0026.md +++ b/dip-0026.md @@ -106,7 +106,9 @@ Version 4 applies to the following special transactions: | ProUpRegTx | 3 | Replaces `scriptPayout` with `payouts`. | This DIP does not change the existing ProUpServTx operator payout field. The -operator payout remains a separate operator-controlled service update field. +operator payout remains a separate operator-controlled service update field, and +the payout list applies only to the owner-controlled portion of the masternode +reward. ### Masternode Payout Share @@ -231,7 +233,10 @@ significant. ### Validation Rules -A version 4 payout list is invalid if any of the following conditions are true: +The following rules apply only to the owner payout list introduced by version 4 +ProRegTx and ProUpRegTx payloads. They do not apply to the existing ProUpServTx +operator payout field. A version 4 payout list is invalid if any of the following +conditions are true: 1. `payoutsCount` is less than 1. 2. `payoutsCount` is greater than 8.