feat!: masternode node hard-fork activation DIP-0023 #5469
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
knst
added a commit
to knst/dash
that referenced
this pull request
Jul 3, 2023
It removes 2 unused flags: - BIP9CheckMasternodesUpgraded from CChainParams - check_mn_protocol from versionbitsinfo These flags have no meaning since 17c792c (PR dashpay#2594) The TODO in removed code is super-seeded by new way to validate MN version in hard-fork (see dashpay#5469 and DIP0023 for more details)
5 tasks
knst
force-pushed
the
mnehf
branch
3 times, most recently
from
03ae77d to
efa899e
Compare
PastaPastaPasta
pushed a commit
that referenced
this pull request
Jul 4, 2023
## Issue being fixed or feature implemented During implementation #5469 (master node hard-fork) I noticed that some parts of `CChainParams` are deprecated and can be removed. ## What was done? 1. removed methods from `CChainParams` that have no implementation at all: - UpdateSubsidyAndDiffParams - UpdateLLMQChainLocks - UpdateLLMQTestParams - UpdateLLMQDevnetParams 2. removed method `BIP9CheckMasternodesUpgraded` from `CChainParams` and a flag `check_mn_protocol` from `versionbitsinfo`. (to follow-up #2594) ## How Has This Been Tested? Run functional/unit tests. ## Breaking Changes N/A ## Checklist: - [x] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
|
This pull request has conflicts, please rebase. |
knst
force-pushed
the
mnehf
branch
2 times, most recently
from
bbcfde3 to
3a11437
Compare
|
This pull request has conflicts, please rebase. |
5 tasks
UdjinM6
pushed a commit
that referenced
this pull request
Jul 25, 2023
## Issue being fixed or feature implemented Current implementation of MnEhfTx is not matched with DIP-0023, this PR fixes it. It is a prior work for #5469 ## What was done? - requestID is fixed from `clsig{quorumHeight}` to `mnhf{versionBit}` + fixes for signature validation properly - v20 is minimal height to accept MnEHF special transactions - versionBit is not BLS version - removed unrelated wrong code and validations - TxMempool will accept MnEHF transaction even if inputs/outputs are zeroes and no fee - implemented python's serialization/deserialization of MnEHF transactions for future using in functional tests ## How Has This Been Tested? Run functional/unit tests. Beside that there's new functional test in #5469 that actually test format of transaction and signature validation - to be merged later. ## Breaking Changes Payload of MnEhf tx is changed, related consensus rules are changed. ## Checklist: - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have added or updated relevant unit/integration/functional/e2e tests - [x] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone
knst
changed the title
knst
requested review from
UdjinM6,
ogabrielides and
PastaPastaPasta
and removed request for
UdjinM6
UdjinM6
requested changes
Aug 5, 2023
Altough, it's still disabled because no calls of related methods after processing MnEHF tx
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
…rder compile flag
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
if a signal is mined prior to nStartTime then it means it was mined for one of the previous deployments with the same bit and we can ignore it
PastaPastaPasta
added a commit
that referenced
this pull request
Oct 18, 2023
Implementation EHF mechanism, part 4. Previous changes are: - #4577 - #5505 - #5469 ## Issue being fixed or feature implemented Currently MN_RR is activated automatically by soft-fork activation after v20 is activated. It is not flexible enough, because platform may not be released by that time yet or in opposite it can be too long to wait. Also, any signal of EHF requires manual actions from MN owners to sign EHF signal - it is automated here. ## What was done? New spork `SPORK_24_MN_RR_READY`; new EHF manager that sign EHF signals semi-automatically without manual actions; and send transaction with EHF signal when signal is signed to network. Updated rpc `getblockchaininfo` to return information about of EHF activated forks. Fixed function `IsTxSafeForMining` in chainlock's handler to skip transactions without inputs (empty `vin`). ## How Has This Been Tested? Run unit/functional tests. Some tests have been updated due to new way of MN_RR activation: `feature_asset_locks.py`, `feature_mnehf.py`, `feature_llmq_evo.py` and unit test `block_reward_reallocation_tests`. ## Breaking Changes New way of MN_RR activation. ## Checklist: - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ --------- Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com> Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
5 tasks
PastaPastaPasta
added a commit
that referenced
this pull request
Nov 10, 2023
## Issue being fixed or feature implemented Addressed issues and comments from [PR comment](#5469 (comment)) and [PR comment](#5469 (comment)) `Params()` should be const; global variable `CMNHFManager` is a better out-come. ## What was done? The helpers and direct calls of `UpdateMNParams` for each block to update non-constant member in `Params()` is not needed anymore. Instead `CMNHFManager` takes cares about status of Signals for each block, update them dynamically and save in evo db. ## How Has This Been Tested? Run unit/functional tests. ## Breaking Changes Changed rpc `getblockchaininfo`. the field `ehf` changed meaning: it's now only a flag -1/0; but it is introduced a new field `ehf_height` now that a height. ## Checklist: - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone --------- Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com> Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com> Co-authored-by: thephez <thephez@users.noreply.github.com>
thephez
added a commit
to dashpay/docs-core
that referenced
this pull request
Nov 13, 2023
* docs: update mnhf with details of final implementation Relates to dashpay/dash#5469 and dashpay/dash#5505 * doc: misc updates and corrections * docs: typo fix
thephez
added a commit
to dashpay/docs-core
that referenced
this pull request
Nov 15, 2023
* docs: deprecate MSG_LEGACY_TXLOCK_REQUEST Aligns with dashpay/dash#5483 * chore: update link to prev version of docs * docs: update mnlistdiff nversion location Relates to dashpay/dash#5450 * docs(p2p): update mnlistdiff Relates to dashpay/dash#5377 * docs: update cbtx for v3 Relates to dashpay/dash#5262 * docs: update mnhf with details of final implementation Relates to dashpay/dash#5469 and dashpay/dash#5505 * docs: note removal of NODE_GETUTXO Relates to dashpay/dash#5500 * chore: revert "docs: update mnhf with details of final implementation" This reverts commit 8e4bf6c since there may still be additional changes to the implementation (it's not merged)
thephez
added a commit
to dashpay/docs-core
that referenced
this pull request
Nov 15, 2023
* docs: update mnhf with details of final implementation Relates to dashpay/dash#5469 and dashpay/dash#5505 * doc: misc updates and corrections * docs: typo fix
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It implements DIP-0023 Masternode EHF: https://github.com/dashpay/dips/blob/master/dip-0023.md
What was done?
Implemented new logic of Hard-fork that takes into account signal from Masternodes.
New manager that processes blocks and extract information about signals and saves them.
+extra fix for by-passing fee limits for this tx.
How Has This Been Tested?
There's new functional test
feature_mnehf.pyBreaking Changes
It changes logic of hard-fork accordingly DIP-0023
Checklist:
TODO:
[x] serialization/deserialization to evoDb
[x] fix issue with index validation for case
ConnectBlock: one block can be connected to differentchainstatebut chainparams are global variables.