-
Notifications
You must be signed in to change notification settings - Fork 219
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
Implement tari_crypto hashing API: ConsensusHasher::default() #4396
Comments
Hi @AaronFeickert, would using the domain separated hashing API for the above hashes be required? We were debating the issue and would like your opinion. Just search for
|
Using (or perhaps even requiring) domain separation seems like an easy win here, unless there is a compelling reason not to. As discussed with @hansieodendaal earlier, the complexity of consensus hashing for the various underlying structs and types would likely make direct use of the hashing API challenging, and probably unnecessarily duplicate a lot of the existing work on those structs' and types' consensus encodings. A better use of engineering effort may be a thorough analysis of those consensus encodings, in order to be certain they are canonical and cannot lead to malicious or accidental collision. I did observe several uses of |
Some context on the |
Yeah, I noticed how the typing was being used in those cases. Agreed that switching to a fixed-length type seems like a wise idea to prevent any future changes that unintentionally introduce collision vectors. |
…onsensus hashing (#4522) Description --- - Added domain hashing to all previous uses of default consensus hashing. - Changed `output_mr`, `witness_mr`, `kernel_mr` and `input_mr` types in `pub struct BlockHeader` to be `FixedHash` instead of variable length `BlockHash`. Motivation and Context --- As per issue #4396. How Has This Been Tested? --- - Passed all unit tests - Passed all cucumber tests
The text was updated successfully, but these errors were encountered: