Quote from: BlueDragon747 on December 28, 2015, 02:37:34 PM

Quote from: decred on December 28, 2015, 12:42:29 AM

Quote from: dbt1033 on December 26, 2015, 10:39:10 PM

Any plans to merge mine with BLC and the other coins in the Blake ecosystem?

Is this 8 round blake?

No plans to merge mine as of yet. Decred is 14-round.

History about SHA3 and Blake-256:
14 rounds was only pushed in final stage sha3 comp as the fear was it was too fast and wanted to win votes from judges to become sha3 but as we know they ended up choosing the next secure hash based on sponge function so others basically got ignored!

Original Blake-256/Blake-32 was 10 rounds and was tested as such so should have 2²⁵⁶ security

you will see with the successor of Blake-256 > Blake2s they reduce the rounds back to 10 anything more is overkill and the whole blake hash design is slightly overkill to start with anyways! Cool

no need to waste compute as it is always going to be there on every platform and may force in some places to spend time/effort doing optimizations when you could start more optimized by factoring the reasons why your hash algo is what it is, tune-able number of rounds is very powerful feature not to be ignored before you start things like root hashes/checksum

so you can look at it like this:

1. ignore and carry on not looking into why you can have 10/8 rounds (huge headache when you find you cant change after)
2. use the 10 round spec and have minimum 2²⁵⁶ security and hash is in big endian so will fit with BTC code
3. use the 8 rounds and have minimum 2²⁰⁰ security (tested so known minimum security with best attack no guess work!)
4. use blake2s or blake2sp and have minimum 2²⁵⁶ security, performance is slightly worse for blake2s vs 8rnd blake-256, blake2 is also little endian so if you wanted to go full on you could remove the big endian conversion and just do everything in little endian as most software does

why did I tweak blake-256 to 8 rounds simple for the wallet you would want a design goal of at least 2¹²⁸ you could do with 2¹⁶⁰ and I thought 2¹⁹² would give enough margin that other flaws in wallet would be of more worry! this seems to have been proven correct so far and the margin on 8 rounds was better than my original estimation @2²⁰⁰ Grin

before anyone starts saying oh but 8 round is only available in c/c++ this is just not true if you care to see my github you will find versions for php/python/java/c/c#/go/opencl

and specifically these may be of interest to the Decred dev/devs

8 round blake-256 in golang
https://github.com/BlueDragon747/blake256

8 round blake-256 checksum tool in golang
https://github.com/BlueDragon747/blakesum

shame about auxpow and merge mining but might be ott in go at this time so much needs to match for it to be valid and with your described pos/pow hybrid it would make far more work for dev/devs, hope that everyone can take some notes about blake-256 it is a good algo but the 14 version is fubar was made only to please judges during final of sha3 which it did not win nor was most of the testing done on 14 rounds!

efficiency is important it helps all nodes even if not mining for as long as you use the algorithm, quicker and higher throughput will lead to quicker propagation time though the nodes on the network if you can save 20-40% off the bat from just understanding the why is blake-256 x rounds and do we really need more security margin than we can use at cost of wasting compute and taking more time?

Hi there, BlueDragon747. While you make some compelling arguments for using 8 or 10 round Blake256 instead of 14 rounds, we are not interested in having Decred merge mined with other Blake256 coins. This choice was intentional and 14 rounds was chosen to be be conservative about security.

Bitcoin uses SHA256(SHA256(data)) to provide potentially more effective security. Boomerang distinguishers attacks are available for 8-round BLAKE256 already. It's unknown what attacks might arise in the future. Therefore, as recommended in the 2010 BLAKE paper from the authors, 14 rounds are used.