Skip to content

docs(dip-26): update masternode multi-party payouts #184

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

Open
PastaPastaPasta wants to merge 10 commits into
base: master
Choose a base branch
from
Open

docs(dip-26): update masternode multi-party payouts #184

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
cbe9150
docs: add masternode reward shares DIP
PastaPastaPasta Jun 5, 2026
aac169b
docs: rename masternode payouts DIP
PastaPastaPasta Jun 5, 2026
3ba2ad2
docs(dip-26): fold multi-party payouts into DIP-26
UdjinM6 Jun 6, 2026
5ac267a
docs(dip-26): scope payout sections to fields this DIP changes
UdjinM6 Jun 6, 2026
5daa60e
docs(dip-26): drop client-specific RPC/JSON section and unused DIP-4 ref
UdjinM6 Jun 6, 2026
84ec174
docs(dip-26): simplify payout sign string
UdjinM6 Jun 6, 2026
e6c1424
docs(dip-26): order payout entry as payout-then-reward
UdjinM6 Jun 6, 2026
f8850ff
docs(dip-26): preserve folded DIP attribution
PastaPastaPasta Jun 7, 2026
9203770
docs(dip-26): address review feedback
thepastaclaw Jun 20, 2026
f8dbe85
Merge pull request #2 from thepastaclaw/fix/dip26-review-followup
PastaPastaPasta Jun 20, 2026
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 [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.

Check failure on line 5 in README.md

View workflow job for this annotation

GitHub Actions / lint

Link text should be descriptive 

README.md:5:174 MD059/descriptive-link-text Link text should be descriptive [Context: "[here]"] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md059.md

## Contributions

Expand Down Expand Up @@ -41,7 +41,7 @@
[23](dip-0023.md) | Consensus | Enhanced Hard Fork Mechanism | Pasta | Standard | Final
[24](dip-0024.md) | Consensus | Long-Living Masternode Quorum Distribution and Rotation | Samuel Westrich & Virgile Bartolo | Standard | Final
[25](dip-0025.md) | Peer Services | Compressed Block Headers | gabriel-bjg, Thephez, UdjinM6 | Standard | Proposed
[26](dip-0026.md) | Consensus | Multi-Party Payout | Timothy Munsell, UdjinM6 | Standard | Proposed
[26](dip-0026.md) | Consensus | Masternode Multi-Party Payouts | Timothy Munsell, UdjinM6, Pasta | Standard | Proposed
[27](dip-0027.md) | Consensus | Dash Core Credit Pool | Ivan Shumkov, Anton Suprunchuk, Thephez, Samuel Westrich | Standard | Proposed
[28](dip-0028.md) | Consensus | Evolution Masternodes | Paul DeLucia, Odysseas Gabrielides, Łukasz Klimek, Ivan Shumkov, Samuel Westrich | Standard | Final
[29](dip-0029.md) | Consensus | Randomness Beacon For LLMQ Selection | Virgile Bartolo | Standard | Proposed
Expand Down
48 changes: 34 additions & 14 deletions dip-0003.md
View file
Open in desktop

@thephez thephez Jun 23, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please match the formatting style of the existing DIP. It does not do line wrapping.

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
Loading
Loading