Skip to content

docs(dip-26): address review feedback #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
PastaPastaPasta merged 1 commit into from
Jun 20, 2026
Merged

docs(dip-26): address review feedback #2

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
48 changes: 34 additions & 14 deletions dip-0003.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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)
Expand Down Expand Up @@ -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)
Expand Down Expand Up @@ -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)

Expand All @@ -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 |

Expand Down Expand Up @@ -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
Expand All @@ -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
Expand Down
9 changes: 7 additions & 2 deletions dip-0026.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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.
Expand Down