In bitcoin#21754, the scriptSig padding multiplier (24) differs from upstream (35) as the vsize value it corresponds to must match what is ordinarily generated (85 vs 96 upstream) in order to fulfill an assertion (source).
In bitcoin#21953, the hash associated with height 200 is generated like this (this is the same method used in dash#5236):
Add the height desired to the CRegTestParams::m_assumeutxo_data map with a garbage hash value (like uint256::ONE). This is to avoid an unrecognized metadata failure (source) caused by looking through the map to see if the height's there.
Change the LogPrintf(..) in the serialized hash check error log message located here to a std::cout << strprintf(..)
Edit the value of mineBlockshere to be 100 blocks less than the desired height.
Compile Dash Core and run ./src/test/test_dash -t validation_chainstatemanager_tests
Take the got value printed to your terminal window/stdout (the expected value should be our garbage value from earlier, ignore that). That's your good hash.
Update the CRegTestParams::m_assumeutxo_data map entry with the correct entry, reverse every change except the map entry (for obvious reasons) and the mineBlocks change.
Remember to add/update the hash here in validation_tests, it simply tests the hardcoded chainparams value with its own hardcoded value. That's also why we don't use this test since it'll just regurgitate the garbage values we give it.
Compile and re-run the test. If it passes, your hash is good. Revert the mineBlocks change.
Profit?
Breaking Changes
None expected.
Checklist:
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas (note: N/A)
[x] I have added or updated relevant unit/integration/functional/e2e tests
[x] I have made corresponding changes to the documentation (note: N/A)
[x] I have assigned this pull request to a milestone (for repository code-owners and collaborators only)
Additional Information
Dependency for https://github.com/dashpay/dash/pull/6138
In bitcoin#21754, the
scriptSigpadding multiplier (24) differs from upstream (35) as thevsizevalue it corresponds to must match what is ordinarily generated (85vs96upstream) in order to fulfill an assertion (source).In bitcoin#21953, the hash associated with height
200is generated like this (this is the same method used in dash#5236):CRegTestParams::m_assumeutxo_datamap with a garbage hash value (likeuint256::ONE). This is to avoid an unrecognized metadata failure (source) caused by looking through the map to see if the height's there.LogPrintf(..)in the serialized hash check error log message located here to astd::cout << strprintf(..)mineBlockshere to be 100 blocks less than the desired height../src/test/test_dash -t validation_chainstatemanager_testsgotvalue printed to your terminal window/stdout(theexpectedvalue should be our garbage value from earlier, ignore that). That's your good hash.CRegTestParams::m_assumeutxo_datamap entry with the correct entry, reverse every change except the map entry (for obvious reasons) and themineBlockschange.validation_tests, it simply tests the hardcoded chainparams value with its own hardcoded value. That's also why we don't use this test since it'll just regurgitate the garbage values we give it.mineBlockschange.Breaking Changes
None expected.
Checklist: