I think it may be a good test case for voting / hard fork : upgrade decred's hashing algo from Blake to Blake2. Links : https://blake2.net/ https://en.wikipedia.org/w/index.php?title=BLAKE_(hash_function)§ion=5#BLAKE2 https://bitbucket.org/dchest/b2sum Arguments: - Not tested as well as the original blake (meant by years, can not evaluate otherwise) + Faster Any ideas ?
BLAKE2 was known about during the development of the chain. The speed gains in BLAKE2 are almost entirely from reducing the number of rounds. The higher round BLAKE was chosen. That said, hard forking should be demoed with voting in the near future.
I suppose newer is better, but it may not always be the case. From links above : "BLAKE2b (or just BLAKE2) is optimized for 64-bit platforms—including NEON-enabled ARMs—and produces digests of any size between 1 and 64 bytes" (so we can have 32 bytes hash) "BLAKE2 includes the 4-way parallel BLAKE2bp ..... tuned to your specific requirements, such as keyed hashing (that is, MAC or PRF), hashing with a salt, updatable or incremental tree-hashing, or any combination thereof." (so it seems like a good fit) Blake2b has 12 rounds. "Based on the security analysis performed so far, and on reasonable assumptions on future progress, it is unlikely that 16 and 14 rounds are meaningfully more secure than 12 and 10 rounds." (and other things mentioned in the paper) just my 2 cents
Hashing with a salt is already supported, but we don't use it. Variable size digest isn't useful to us, and native 64-bit may also not be useful for embedded devices. ChaCha20 has a solid history of secure use in the Poly1305-ChaCha20 suite. It is used by both Cloudflare and Google. The G rounds in BLAKE are also able to be made parallel for BLAKE256, as noted in Aumasson et al (2014) section 6.2.1. Tree hashing isn't interesting because the method used is for generating hashes of large contiguous files with fixed leaf sizes, which our data is not. This feature is intended to speed up the hashing of large files by allowing high parallelization, but a cryptocurrency only hashes small headers and variably sized transactions, the majority of which are small. We took note of this earlier (it was in the published book on BLAKE mentioned above), but we wanted to choose a hashing function with conservative security parameters. Notice that SHA256d was chosen instead of SHA256 for Bitcoin. BLAKE2 is intended to be a replacement for a fast replacement for MD5, a very fast but later determined to be insecure algorithm. We erred on the side of security.
I am no crypto expert and I do care about security of Decred. But the tweet you mentioned is 2 years old already and everybody can compare "That does sound okay, but I can't decide if 64b is going to propagate into all the embedded devices I care about." with today's market. Linux kernel already decided to drop 32 bit support. Second link does not work, but Cloudflare mentioned ChaCha20 implementation more than a year ago. And as the mentioned it was invented by Professor Dan Bernstein (djb) back in 2008. And BLAKE and BLAKE2 are based on it. A security comparision of sha256, sha256d, md5 and Blake/2 can be searched for, but as Blake2 PDF says in chapter 4 Security - the most advanced attacks on the BLAKE as hash function—as opposed to its building blocks—are preimage attacks on 2.5 rounds with respective complexity 2^241 for BLAKE-256 ... "we expect attacks on reduced BLAKE with n rounds to adapt to BLAKE2 with n rounds, though with slightly different complexities". My concern is to create a cryptocurrency for the future, not dwell in the past.