Topic: Cryptocoin Algorithm Comparison (Read 824 times)

Asic resistance is not a temporal property.
Scrypt was never particularly asic-resistant.

And neither is X11.
Everybody expects X11 ASICs to arrive sooner or later once it's profitable enough,
e.g. once X11 coins exceed Litecoin in market-cap (which seems unlikely to ever happen).

It would appear that many (dozens? hundreds?) MB of memory are needed to provide decent ASIC resistance.
Ethereum's ethash, which requires 1GB for efficient mining, can be said to be pretty ASIC resistant.

Thank you so much MaxDZ8! Thats exactly what i was looking for! and with links for further research!

Your friend with a thing for Skein, does he happen to run a "pure", logarithmic skein coin lol?

It's intriguing to me that each of the algo's that make up the 'x' series coins, " have no ASIC resistance while some are explicitly ASIC friendly." And yet each of these algo's combined into one chain seems to be somewhat 'asic-resistant', at least so far.

It seems I have lots more to learn, thank you again for showing me where to get started

Most of the algorithms you have cited are SHA3 candidates. They can be better investigated at the SHA3 zoo or WP:EN.

Most of them have no ASIC resistance while some are explicitly ASIC friendly.

The 256 bit variation is not very relevant. The structure is basically the same for most of them and they are stronger or weaker as you would expect.

My impression about some I have taken a look at:

• Blake is possibly one of the best, mostly because its cipher function essentially set a new gold standard
• Groestl is relatively simple to understand but the simplicity does not map to implementation. It is heavily S-box based using AES round. In practice it isn't much of a big deal, albeit it's probably one of the strongest security competitors
• Keccak is SHA3 winner because of its extreme ASIC friendliness
• A friend of mine has a thing for Skein. Apparently it performs very nicely on all kinds of hardware (ASICs are faster, but not considerably faster) which means everyone can have access to a reasonably efficient implementation (OR: nobody can have an immensely faster one). I have to admit I agree with him.
• Luffa is pretty ugly. It's most likely optimized to produce extremely little ASICs for use in embedded systems.
• Pretty much the same for ShaVite3.
• CubeHash is awesome. It was not designed by a 'pure' cryptographer but rather a security expert fluent in cryptography. It has an unique construction and plenty of parameters which allows it to adapt on a wide range of hardware. Cryptographic bandwidth is also high and it's most likely the easier to implement (for some parameter set). I honestly have a thing for this, even though it isn't a finalist.
• Something is seriously wrong with SIMD. Apparently under some circumstances the output is considerably different from a random oracle (I cannot hit the right keywords now). SIMD is complicated in both theory and implementation using some constructs which are not purely cryptographic in nature. The complexity produces a low cryptographic bandwidth and the benefits are not even well proven.
• ECHO is somehow nice, relatively simple and parallelizable.

The idea of scrypt is to accumulate various hashes (except they are not hashes: they are block ciphers, but that's not considerably different for the purpose of discussion) and use their effectively random bits to force memory usage. Because memory is slower than computation, they speculate this increases security as a brute force attack cannot access any faster architecture (memory is memory, and commercial RAM is rather efficient).
If you ask a 'pure' cryptographer they'll tell you that this kind of approach is pretty weak compared to higher complexity functions or tuning parameters, or new designs. I even read a paper by Intel (I think) stating this. That's probably true in theory.
In practice, high memory usage is the only thing that keeps ASICs at bay but due to some debatable decisions, ASICs for scrypt-1024 are viable.

Scrypt-jane uses the structure of scrypt using different block ciphers (such as Blake). It is not considerably different. Scrypt-jane is really a framework to produce "variation" of scrypt as far as I've understood.

Another few things you might have heard of...

• Neoscrypt: I don't even remember what was the point with this. It was introduced to avoid scrypt ASICs... they could have used any ready-to-go function but instead they decided to go with this. It does mix-and-match with various building blocks to (apparently) increase complexity of chip design, which I find debatable. The extreme arithmetic intensity implies an eventual ASIC for this will have a huge advantage.
• yescrypt: it is super complicated. You'll need a few beers to see the similarity with basic scrypt. The bottom line with yescrypt is that it needs a 64bit ADD and fast, low-latency memory. There's basically no arithmetic intensity at all so there's nothing to accelerate. It is extremely effective at avoiding the issues with scrypt. Cryptographically speaking it's built on basic SHA256 so "in theory" it isn't much of a big deal. In practice the thing is effective even though I don't see any context in which it works as the extreme cache usage will make everything else running on the same system go super-slow but I'm not really that familar with hi-end server chips.
• M7: just another chained hashing scheme using old cryptographic functions. In theory, those should be considered obsolete after SHA3 competitions have been held but they're not 'utterly broken' either so somebody decided to give them a go.
• M7M(v2): M7 hashes are fetched to non-cryptographic constructs (arbitrary precision arithmetic by gmplib).
• Tromp's Cuckoo cycles based PoW: because there's more to throwing away energy to compute random numbers, we can throw away energy to walk random graphs. No idea why this is better than just hashing stuff, I'm most likely missing something. In the end it doesn't matter as nobody uses it...
• ... albeit Ethereum PoW apparently involves walking a DAG somehow, which might have some similarity or not (I haven't looked at either).

it's not so important which algo, every one is exellent.

Awesome thank you for the link, reading now

You may want to read this article

http://cryptorials.io/beyond-hashcash-proof-work-theres-mining-hashing/

explaining there's more to mining than hashing.

Hello all bitcointalk members! (specifically developers)

I am looking into some of the hashing algo's used in todays cryptocoins, and am hoping someone here can give me a bit more insight. Basically what i looking for is a few informed individuals who can give me some pro's and con's , aswell as personal opinions, on the different available algorithms.
(Why they are good for cryptocoins specifically, whether they are "asic-resistant", etc)
For the most part, im looking for answers from the developers point of view, however miners opinions are always usefull aswell!

Algo's im specifically interested in:
blake512, bmw512, groestl512, JH512, Keccak512, Skein512, Luffa512, Cubehash512, Shavite512, Simd512, Echo512, Hamsi512, Fugue512, Shabal512, Whirlpool.
Aswell as each of their 256 counterparts.

Other's of some interest:
Blake2b, Scrypt-n, Scrypt-Jane.

Any insight into these cryptographic algo's would be greatly appreciated. (a short laymans version is fine... no need for intense detail )
I am currently in the process of researching each of these myself... however tbh alot of what i've found is explained in a way that is far beyond my understanding.