Change Details

> Test with block 47 in the feature_block.py creates a block with a hash higher than the target, which is supposed to fail. Now two issues exist there, and both have low probability of showing up: > > The creation is done with while (hash < target), which is wrong, because hash = target is a valid mined value based on the code in the function CheckProofOfWork() that validates the mining target: > > ``` > if (UintToArith256(hash) > bnTarget) > return false; > ``` > > As we know the hash stored in CBlock class in Python is stateful, unlike how it's in C++, where calling CBlock::GetHash() will actively calculate the hash and not cache it anywhere. With this, blocks that come out of the method next_block can have incorrect hash value when solve=False. This is because the next_block is mostly used with solve=True, and solving does call the function rehash() which calculates the hash of the block, but with solve=False, nothing calls that method. And since the work to be done in regtests is very low, the probably of this problem showing up is very low, but it practically happens (well, with much higher probability compared to issue No. 1 above). > > This PR fixes both these issues. This is a backport of Core [[https://github.com/bitcoin/bitcoin/pull/18350 | PR18350]]

> Test with block 47 in the feature_block.py creates a block with a hash higher than the target, which is supposed to fail. Now two issues exist there, and both have low probability of showing up: > > - The creation is done with while (hash < target), which is wrong, because hash = target is a valid mined value based on the code in the function CheckProofOfWork() that validates the mining target: > > ``` > if (UintToArith256(hash) > bnTarget) > return false; > ``` > > - As we know the hash stored in CBlock class in Python is stateful, unlike how it's in C++, where calling CBlock::GetHash() will actively calculate the hash and not cache it anywhere. With this, blocks that come out of the method next_block can have incorrect hash value when solve=False. This is because the next_block is mostly used with solve=True, and solving does call the function rehash() which calculates the hash of the block, but with solve=False, nothing calls that method. And since the work to be done in regtests is very low, the probably of this problem showing up is very low, but it practically happens (well, with much higher probability compared to issue No. 1 above). > > This PR fixes both these issues. This is a backport of Core [[https://github.com/bitcoin/bitcoin/pull/18350 | PR18350]]

> Test with block 47 in the feature_block.py creates a block with a hash higher than the target, which is supposed to fail. Now two issues exist there, and both have low probability of showing up: > > - The creation is done with while (hash < target), which is wrong, because hash = target is a valid mined value based on the code in the function CheckProofOfWork() that validates the mining target: > > ``` > if (UintToArith256(hash) > bnTarget) > return false; > ``` > > - As we know the hash stored in CBlock class in Python is stateful, unlike how it's in C++, where calling CBlock::GetHash() will actively calculate the hash and not cache it anywhere. With this, blocks that come out of the method next_block can have incorrect hash value when solve=False. This is because the next_block is mostly used with solve=True, and solving does call the function rehash() which calculates the hash of the block, but with solve=False, nothing calls that method. And since the work to be done in regtests is very low, the probably of this problem showing up is very low, but it practically happens (well, with much higher probability compared to issue No. 1 above). > > This PR fixes both these issues. This is a backport of Core [[https://github.com/bitcoin/bitcoin/pull/18350 | PR18350]]