Implement computing SHA256 in const context #1769
Conversation
|
The integration test "failures" look like a series of annoying warnings that we've promoted to errors. concept ACK this (and will give a real ACK soon). Are the warnings about efficiency purely because we use As for the question about macro syntax, I prefer the |
|
I don't see any loop errors, just operator precedence. I think I'll We could also have |
|
Oh, now I understood your question about loops. 🤦♂️ Yes, and you are probably right, I tried some stuff in godbolt and looks good. However there's still a reason to consider it: we may move to use native CPU instructions. There are discussions about conditionally running different code in Although honestly I'm kinda tempted to do it and thus enable a bunch of things in |
Computing hashes in const fn is useful for esily creating tags for `sha256t`. This adds `const fn` implementation for `sha256::Hash` and the algorithm for computing midstate of tagged hash in `const` context. Part of rust-bitcoin#1427
91f45a2 Replace hardcoded values with compile-time hashing (Martin Habovstiak) 095b795 Make `sha256t_hash_newtype!` evocative of the output. (Martin Habovstiak) Pull request description: The Rust API guidelines state that macros should be evocative of the output, which is a sensible recommendation. We already had this for `hash_newtype!` macro but didn't for sha256t version. This changes the macro to have this syntax: ```rust sha256t_hash_newtype! { // Order of these structs is fixed. /// Optional documentation details here. Summary is auto-generated. /*pub*/ struct Tag = raw(MIDSTATE_BYTES, LEN); /// Documentation here #[hash_newtype(forward)] // optional, default is backward /*pub*/ struct HashType(/* attributes allowed here */ _); } ``` Closes #1427 Depends on #1769 How do you like the syntax? Is weird `struct Foo = bar(..);` acceptable? ACKs for top commit: tcharding: ACK 91f45a2 apoelstra: ACK 91f45a2 Tree-SHA512: f6b555b20311a4c1cb097bc296c92459f6fbe16ba102d8c977eb2383dbcae3cc8ffce32e3cb771e7e22197fda26379971aa4feaadc5e2e70d37fa690ae8b8859
Computing hashes in const fn is useful for esily creating tags for
sha256t. This addsconst fnimplementation forsha256::Hashand the algorithm for computing midstate of tagged hash inconstcontext.Part of #1427
I'd like to make sha256t evocative of the output after this which would also do the thing we want to do with #1427 (awkward language to bypass GH automatically closing it...) I'm thinking of this:
What do you think? I was also thinking about this alternative:
Which looks more natural but maybe too much boilerplate? Which one do you like? Any better ideas? Heads up sanket1729
Also FYI tcharding this is the kind of post-1.48 change I was thinking about. :)