-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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.
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
feat: improvements for v19, v20 and dip3 - fire up test chains by first block 5/n #6269
Conversation
@@ -53,18 +53,11 @@ static bool CheckSpecialTxInner(CDeterministicMNManager& dmnman, const Chainstat | |||
} | |||
return CheckMNHFTx(chainman, qman, tx, pindexPrev, state); | |||
case TRANSACTION_ASSET_LOCK: | |||
if (!DeploymentActiveAfter(pindexPrev, consensusParams, Consensus::DEPLOYMENT_V20)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why keeping similar checks for "unlock" and "mnhf" if we drop this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@UdjinM6 don't we normally keep checks like this? for stuff like new devnets, or in case someone is sending us a bad fork I guess?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what will happen if someone will send us a bad fork for devnet? If fork will be accepted - that's fine, whatever it has asset-unlock/mnehf/etc transaction or not. we have chainlocks also.
That's important to keep conditions like that if they change behavior incompatible way. For example DIP0001 has not only introduced a bigger blocks size, but also introduced a limit for size of transaction and some old blocks do not satisfy that requirement. So, for that type of consensus condition we should keep it, otherwise mainnet/testnet can't re-sync properly for old blocks. But there's completely fine.
Can you show in our code base any condition like that which we keep intentionally over-versions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, we have all soft-forks on all devnets activated from blocks 300 (soon from block 2), so, it should not be a problem also
https://github.com/dashpay/dash/pull/6187/files#diff-ff53e63501a5e89fd650b378c9708274df8ad5d38fcffa6c64be417c4d438b6dL568-L573
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with headers-first sync and assumevalid in place these checks do not matter that much anymore and we can drop them safely imo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK 4950be0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK 07c510f
This pull request has conflicts, please rebase. |
07c510f
to
c422e37
Compare
rebased due to conflict with #6271 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rebase looks clean
re-utACK c422e37
c422e37
to
8411fc9
Compare
if (Params().NetworkIDString() != CBaseChainParams::REGTEST && !DeploymentActiveAfter(pindexPrev, consensusParams, Consensus::DEPLOYMENT_MN_RR)) { | ||
return state.Invalid(TxValidationResult::TX_CONSENSUS, "assetunlocks-before-mn_rr"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as before comment, re: devnets bad chain etc?
if (!DeploymentActiveAfter(pindexPrev, consensusParams, Consensus::DEPLOYMENT_V20)) { | ||
return state.Invalid(TxValidationResult::TX_CONSENSUS, "mnhf-before-v20"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same
This pull request has conflicts, please rebase. |
8411fc9
to
cad8aff
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK cad8aff
Force pushed due to CI failure after rebase. There's extra fix now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK cd037ad
This pull request has conflicts, please rebase. |
cd037ad
to
0da73ac
Compare
0da73ac
to
643f9bc
Compare
V20 is activated long time on mainnet and testnet, so, it doesn't matter anymore
…works It simplify implementation and unify RegTest, Mainnet and Testnet No asset-unlock transaction has actually be mined yet, but v20 and mn_rr are activated long time ago. So, this changes are not breaking changes
… from unit tests It takes time to update each checkpoint if any forks changes in unit tests: new height, new bit, and extra params. Reduced scope of changes for future updates
It also change dip3params default from 30:50 to 2:2 De facto, that always equals True, so, there's no meaning to have it
It is not a breaking changes, because this fork is already happened in past and no EHF transaction is in blockchain at that moment which requires versioning
This fork already happened and no versioning is required
643f9bc
to
6030611
Compare
last 2 force-pushes due to rebase mistakes |
what a journey! @PastaPastaPasta please, help with this PR finally |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK 6030611
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK 6030611
…ck - 6/n 9a9d0d5 feat: drop SPORK 24 (EHF) so far as this feature works on testnet / mainnet (Konstantin Akimov) da0dc06 perf: optimize feature_mnehf.py by generating less blocks (Konstantin Akimov) 0de3923 feat: bury fork mn_rr (masternode reward reallocation) (Konstantin Akimov) Pull request description: ## Issue being fixed or feature implemented MN_RR is activated on mainnet: time to bury it! ## What was done? Hard-fork mn_rr is buried. Prior fixes are done here: #6270 and #6269 ## How Has This Been Tested? Run unit and functional tests ## Breaking Changes N/A ## 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 ACKs for top commit: UdjinM6: light ACK 9a9d0d5 PastaPastaPasta: utACK 9a9d0d5 Tree-SHA512: 73ea0ca1270f15f6f1193efbaf402d476c84e9a843af85b7eae3e40199f4c943ad40f58e062b8db20e1c5c69c1a85579ebaf0722f1044ee2e1a4e7f96c58e645
Issue being fixed or feature implemented
This PR is 5th in the achieving ultimate goal to activate old forks from block 1.
It helps to run unit and functional tests faster; it helps for platform's dev-environment to start faster.
What was done?
fast_dip3_enforcement=True
from functional tests which is always trueHow Has This Been Tested?
Run unit and functional tests
tsan
job runs 500 seconds faster of real time and 2000seconds faster for "accumulated time"https://gitlab.com/dashpay/dash/-/jobs/7817453421 - this PR
https://gitlab.com/dashpay/dash/-/jobs/7805625816 - some old PR for reference
No breakdown per tests here, because they affect each other and runs in parallel.
Breaking Changes
Regtest has v20 activated on same block as v19 if otherwise is not specified with
-testactivationheight=v20@1200
Checklist: