Infrastructure for changing the hash function #894
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for more selecting the POW hash algorithm based on chainweb version and block height. It also adds support for allowing more than a single POW hash algorithm at the same block height.
In detail:
Move
BlockHeight
into its own module.Add a
PowHashAlg
enumeration type.Add a chainweb version property
ChainwebVersion -> BlockHeight -> [(PowHashAlg, Natural)]
, where theNatural
number designates the multiplier for difficulty of the respective algorithm.Use the first byte (actually, currently only the first bit) of the features flags in the
BlockHeader
to indicate the POW hash algorithm that is used.Add validation logic to verify that the a block header uses a hash algorithm that is supported for the respective chainweb version and block height.
Change validation logic to include the multiplier for the POW hash when checking the target.
Add a utility function for transitioning between two algorithms while keeping the block rate constant.
Address FIXMEs in
Chainweb.PowHash
.Adapt implementation in
Chainweb.Miner.Core
to select the correct POW hash.Add selection of hash algorithm to mining coordinator configuration.
This PR also contains an unrelated bug fix, that adds a validation rule that verifies that unused features flags are set to 0. Important: Complete history catchup and validation must be performed before rolling this out.