-
Notifications
You must be signed in to change notification settings - Fork 38.6k
test: Check that no versionbits are re-used #21691
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
Conversation
ajtowns
left a comment
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.
Concept ACK
|
Concept ACK. I agree that #21691 (comment) is a better way of adding this test. |
|
(not for backport, obviously) |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
fa8016d to
fabcfe3
Compare
This allows to remove check that windows for the same bit are disjoint This addresses bitcoin#21377 (comment)
fabcfe3 to
fabe30b
Compare
fabe30b to
fa8eaee
Compare
|
Concept ACK |
ajtowns
left a comment
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.
ACK fa8eaee code review only
| } | ||
| } | ||
|
|
||
| BOOST_AUTO_TEST_CASE(versionbits_sanity) |
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.
I think it would be better to keep the "check the params make sense" checks separate from the "check ComputeBlockVersion does the right thing" checks.
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.
the sanity checks are a requirement, so they need to be run as part of the same test case. Do you mean to split them up into a separate function? I think that'd be too verbose, but I am happy to take a diff if you happen to have 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.
Yeah, maybe you're right -- can't reliably test computeblockversion if some other deployment might start setting the bit in question as soon as it hits ACTIVE, even if they're not technically overlapping. No need to hold this up over it in any event.
|
Code review ACK fa8eaee |
jonatack
left a comment
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.
Could pick up the suggestions by sipa at #21377 (comment) and I to make these const or reference to const
int64_t bit = params.vDeployments[dep].bit;
int64_t nStartTime = params.vDeployments[dep].nStartTime;
int64_t nTimeout = params.vDeployments[dep].nTimeout;
int min_activation_height = params.vDeployments[dep].min_activation_height;| { | ||
| BOOST_CHECK_EQUAL(min_activation_height, 0); | ||
| return; | ||
| } |
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.
@@ -271,8 +367,7 @@ static void check_computeblockversion(const Consensus::Params& params, Consensus
// always/never active deployments shouldn't need to be tested further
if (nStartTime == Consensus::BIP9Deployment::ALWAYS_ACTIVE ||
- nStartTime == Consensus::BIP9Deployment::NEVER_ACTIVE)
- {
+ nStartTime == Consensus::BIP9Deployment::NEVER_ACTIVE) {
BOOST_CHECK_EQUAL(min_activation_height, 0);
return;
}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.
Personally I find it incredibly ugly to have the if-condition and the first if-branch continue with the same indentation as if they are one block. It might be good to update the clang-format to not do this.
Also this file is far from clang-format clean, so I am going to leave as is for 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.
@MarcoFalke CONCEPT ACK
|
Sanity check on the values in for (const auto& chain_name : {CBaseChainParams::MAIN, CBaseChainParams::TESTNET, CBaseChainParams::SIGNET, CBaseChainParams::REGTEST}) {
+ BOOST_TEST_MESSAGE(strprintf("chain: %s", chain_name));
const auto chainParams = CreateChainParams(*m_node.args, chain_name);
uint32_t chain_all_vbits{0};
for (int i = 0; i < (int)Consensus::MAX_VERSION_BITS_DEPLOYMENTS; ++i) {
@@ -426,8 +427,16 @@ BOOST_AUTO_TEST_CASE(versionbits_computeblockversion)
// the same bit might overlap, even when non-overlapping start-end
// times are picked.
const uint32_t dep_mask{VersionBitsMask(chainParams->GetConsensus(), dep)};
+ BOOST_TEST_MESSAGE(strprintf("i: %d", i));
+ BOOST_TEST_MESSAGE(strprintf("dep_mask: %d", dep_mask));
+ BOOST_TEST_MESSAGE(strprintf("chain_all_vbits: %d", chain_all_vbits));
BOOST_CHECK(!(chain_all_vbits & dep_mask));
chain_all_vbits |= dep_mask;
+ if (i == 0) {
+ BOOST_TEST_MESSAGE(strprintf("updated chain_all_vbits after |= dep_mask: %d", chain_all_vbits));
+ } else {
+ BOOST_TEST_MESSAGE("\n");
+ }
check_computeblockversion(chainParams->GetConsensus(), dep);
}
} |
Left this as is for now to not invalidate reviews |
fa8eaee test: Run versionbits_sanity for all chains (MarcoFalke) faec1e9 test: Address outstanding versionbits_test feedback (MarcoFalke) fad4167 test: Check that no versionbits are re-used (MarcoFalke) Pull request description: ACKs for top commit: jnewbery: Code review ACK fa8eaee ajtowns: ACK fa8eaee code review only Tree-SHA512: e99ffcca8970921fd07fa9e04cf1ea2515a317409865d34ddfd70be0f0b0616b29d1fad58262d96a3c3418c0cf7018a6a955802a178b8f78f6ecfaa30a37d91c
No description provided.