Add implementation of hash160 #124
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 the function
hash160.The algorithm for
ripemd160(which is part ofhash160withsha256) is described in this paper.I had a few options for the implementation, depending on the factors I wanted to prioritize: code size, speed, readability, or maintainability.
It is possible to write this algorithm with a single loop that dispatches the functions used depending on the iteration, or to unroll it completely.
At first, I did the intermediate implementation: the compression consists of 5 loops with 16 iterations, which all use the same function inside. It was a nightmare: the code was several hundredth lines long, and any bug in a loop had to be fixed in all loops.
I decided then to go to the single loop with 80 iterations. The function dispatch is done by looking in a table for the function to pick. This implementation is less fast (because of the
call_indirect), but is 5 times smaller than the previous one.Still, if we find later that this implementation might be too slow, it is possible to rewrite it and unroll it by hand.
It was also possible to compute during runtime some of the values that are used in this algorithm. I decided to precompute them all and to store them in memory (360 bytes total). Another possibility here would have been to compute them with
v128.I unilaterally decided that we could use 360 bytes and avoid some calculations at runtime.
As for #117 , there are no property tests. This algorithm has massive changes in the results for any single mistake, so the fact that the current tests work can give us confidence that this implementation is correct.
Still, we should add some in the future.
Closes #69