Skip to content

docs: update dip-0023 - removed mentions of non existing min_activation_height #153

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
thephez merged 4 commits into from
Jul 22, 2025
Merged

docs: update dip-0023 - removed mentions of non existing min_activation_height #153

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d757c4f
docs: update dip-0023 - removed mentions of non existing min_activati…
knst Jul 19, 2024
0246fd6
docs: changed status of proposal DIP-0023 to Final
knst Jul 19, 2024
07c449b
fix: typos and wording
knst Jul 21, 2025
6f8d28b
fix: updated header of dip-0023
knst Jul 21, 2025
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 @@ -36,7 +36,7 @@
[20](dip-0020.md) | Consensus | Dash Opcode Updates | Mart Mangus | Standard | Final
[21](dip-0021.md) | Consensus | LLMQ DKG Data Sharing | dustinface | Standard | Final
[22](dip-0022.md) | Consensus | Making InstantSend Deterministic using Quorum Cycles | Samuel Westrich, UdjinM6 | Standard | Final
[23](dip-0023.md) | Consensus | Enhanced Hard Fork Mechanism | Pasta | Standard | Proposed
[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
Expand Down
27 changes: 9 additions & 18 deletions dip-0023.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,9 @@
DIP: 0023
Title: Enhanced Hard Fork Mechanism
Author(s): Pasta
Special-Thanks:
Special-Thanks: Konstantin Akimov
Comments-Summary: No comments yet.
Status: Proposed
Status: Final
Type: Standard
Created: 2021-07-29
License: MIT License
Expand Down Expand Up @@ -47,8 +47,8 @@ setting the start timestamp to a month or two after the release.

## New System

**Stage 0:** Miners signal without any effect on consensus. It is impossible to lock-in at this
point. The purpose of this signalling is to enable monitoring of which miners have upgraded their
**Stage 0:** Miners signal without any effect on consensus. It is impossible to move beyond the `defined`
state at this point. The purpose of this signalling is to enable monitoring of which miners have upgraded their
software and get an idea of the adoption rate. Additionally, it is important to note that this
signalling does not take up any space, and as such there is no incentive to minimize the time where
signalling is done.
Expand All @@ -75,26 +75,17 @@ The payload of the Masternode Hard Fork Signalling Transaction (the new special
| version | uint_8 | 1 | Commitment special transaction version number. Currently set to 1. Please note that this is not the same as the version field of the `mnhfsignal` message |
| commitment | mnhfsignal | 129 | This equals the payload of the `mnhfsignal` P2P message

**Stage 2:** Once this `mnhfsignal` message has been mined, two parameters are set:
`masternode_activation_height` and `min_activation_height`. The cycle beginning at
`masternode_activation_height` is the first cycle where miner signalling matters. Its starting
height is calculated based on the `mnhfsignal` message height as shown here:
**Stage 2:** Once this `mnhfsignal` message has been mined, the `masternode_activation_height` parameter
is set. The cycle beginning at `masternode_activation_height` is the first cycle where miner
signalling matters. Its starting height is calculated based on the `mnhfsignal` message height as shown here:

masternode_activation_height = mined_height - (mined_height % 4032) + 4032

This cycle’s threshold is `nThresholdStart` (the maximum threshold value). Each subsequent cycle
will see its threshold decreased until it reaches `nThresholdMin` (the minimum threshold value).

Regardless of miner signalling, activation only occurs once the height defined by the
`min_activation_height` parameter is met. This is set to be 6 signalling windows (~6 weeks) after
the `masternode_activation_height`. It is calculated as shown here:

min_activation_height = masternode_activation_height + 4032 * 6

If the threshold is met at the end of a cycle, `activation_height` is calculated by each node as
shown here:

activation_height = max((height + 4032), min_activation_height)
Once a new cycle starts after `masternode_activation_height`, activation depends only on miner signalling.
The status may now move beyond `defined` and proceed to `started`, `locked_in` and `active` if miner signalling occurs.

## Timeout

Expand Down
Loading