-
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: start DIP0024 from block 1 - fire up test chains by first block - 7/n #6325
Conversation
6a16b30
to
a320a6c
Compare
a320a6c
to
8073334
Compare
converted to draft because |
This pull request has conflicts, please rebase. |
8073334
to
7c39ab2
Compare
This pull request has conflicts, please rebase. |
This pull request has conflicts, please rebase. |
e0bcb0a
to
80ef2b2
Compare
61bf984
to
cd2f39a
Compare
CI seems succeed now, please help to review it @UdjinM6 @PastaPastaPasta I believe there's still some underlying issue remain in our llmq-code or in our test_framework, because every time something relevant changed, the functional test feature_llmq_simplepose.py becomes unstable: |
This pull request has conflicts, please rebase. |
It can happen because now order of activation of hardforks v20, mn_rr, dip3 can be changed by using testactivationheight on Regtest and no more guarantee about this assertions
bip147height is superseeded by -testactivationheight=bip147@height dip8params is superseeded by -testactivationheight=dip0008@height
For current implementation it is not important when exactly fork happened yet important to know when first rotating quorum formed
cd2f39a
to
5092207
Compare
ok, I fixed intermittent error in feature_llmq_simplepose.py. See 5ec071a What a twist!!! |
Looks good overall but 45bf353 and 5092207 change nothing for me, tried many times and 1-2 out of 8 jobs are failing with or without these commits. And it feels more like we are hiding the underlying issue rather than fixing it, would prefer them dropped. Also, backport commits should be in their own PR imo. |
5ec071a
to
f1905ca
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 f1905ca
@@ -114,17 +114,20 @@ void CCreditPoolManager::AddToCache(const uint256& block_hash, int height, const | |||
|
|||
static std::optional<CBlock> GetBlockForCreditPool(const CBlockIndex* const block_index, const Consensus::Params& consensusParams) | |||
{ | |||
// There's no CbTx before DIP0003 activation | |||
if (!DeploymentActiveAt(*block_index, Params().GetConsensus(), Consensus::DEPLOYMENT_DIP0003)) { |
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.
block_index can be null here?
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.
it seems unrelated because it was used in ReadBlockFromDisk
before without extra checks:
bool ReadBlockFromDisk(CBlock& block, const CBlockIndex* pindex, const Consensus::Params& consensusParams)
{
const FlatFilePos block_pos{WITH_LOCK(cs_main, return pindex->GetBlockPos())};
Anyway, I added extra annotations just in case, see a new commit
const bool fDIP0024IsActive{optDIP0024IsActive.value_or(DeploymentActiveAfter(pindexPrev, consensusParams, Consensus::DEPLOYMENT_DIP0024))}; | ||
const bool fHaveDIP0024Quorums{optHaveDIP0024Quorums.value_or(pindexPrev->nHeight >= consensusParams.DIP0024QuorumsHeight)}; | ||
const bool fDIP0024IsActive{ | ||
optIsDIP0024Active.value_or(DeploymentActiveAfter(pindexPrev, consensusParams, Consensus::DEPLOYMENT_DIP0024))}; |
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.
nit: we should rework this, currently this will always call DeploymentActiveAfter as it's a param. Should put in a lambda or something to avoid calling DeploymentActiveAfter if optIsDIP0024Active is set
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.
we discussed it, this optIsDIP0024Active
is used only for Unit test and it means that on production (mainnet, testnet, any devnet) it would be a case of OR in value_or
for 100% calls. Not close to 100%, but indeed each one. So, this optimization won't give any extra benefits.
Also just a side note (not really important in this particular case) the function DeploymentActiveAfter
for buried deployment (which is DIP0024) is simplified to one single if
condition with height comparision, so, there's not much calculation is done anyway
bb82af5
to
906c2d7
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 906c2d7
pls update PR title
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 906c2d7
Issue being fixed or feature implemented
This PR is 7th 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?
Prior work: #6187, #6189, #6214, #6225, #6269, #6275
This PR:
How Has This Been Tested?
Run unit, functional tests.
Breaking Changes
[regtest only] -dip8params, -bip147height are removed.
Checklist: