Is the Zcash mining algorithm designed to be CPU and GPU agnostic?


#1

Or one of these processor architectures has the advantage?


#2

We won't have the answer to this until someone releases a GPU miner.

Based on what I've read on other threads, the people that have coded their own GPU miners are at an advantage.


#3

Really? I would expect this being a known issue since the Zcash team seems to have a really good background in crypto and computer science, and they should know that a GPU/CPU agnostic algo is the best way to go if you want to promote decentralization. For example, Monero uses a "memory heavy" mining algorithm that helps to level the playfield between GPU and CPU.


#4

Monero's PoW, CryptoNight, with its 2MB memory requirement, is much less memory heavy than Zcash's Equihash, which requires 100s of MBs.

Cryptonight is also much less hardware agnostic, heavily favouring Intel CPUs with native AES-NI support.

Finally, Cryptonight has the disadvantage of not being instantly verifiable, a desirable quality for a PoW...


#5

This is the kind of answer I was looking for, thanks! It is nice to see all the thoughtful work the Zcash team is doing, so I have assumed that you were also pushing for hardware decentralization, and Equihash seems like a sweet solution to that. I was reassured by your answer and by this post I found were it is explained that by using the Equihash algorithm it is unlikely that further optimisations would give too much of an advantage to certain miners, since any optimisation to the algorithm would need to be an optimisation to the Generalized Birthday Problem, giving to the Equihash algorithm a hard mathematical barrier to unevening the playfield between hardware.

Also it was nice to learn that the Zcash team is willing to change the PoW algorithm if a flaw is found against this issue.

What do you mean by "100s of MBs"? If you don't mind...

Thanks again for your answer!


#6

There's no such thing as a "hard mathematical barrier" and the published implementations of Equihash are already known to be suboptimal by at least an order of magnitude.

At this point (about one month from launch) the Zcash team can no longer change the PoW no matter what flaws are found. That will have to be dealt with in a later update.

100s means hundreds, e.g. several hundred.


#7

I see. So, what about this statement?

This is because the Generalized Birthday Problem has been widely studied by computer scientists and cryptographers, and Equihash is close to the Generalized Birthday Problem. That is: it looks like a successful optimization of Equihash would be likely also an optimization of the Generalized Birthday Problem.

And,

The post was referring to changing the PoW ONLY before launching? I thought it meant that the PoW could be changed anytime if it is found that it's not so hardware agnostic.


#8

It shows that despite wide study, optimizations could still be found.

I guess the PoW could be changed anytime except for some 2 month window around launch...


#10

What is the best solution you think now? Is pow the right way? After release version , can zcash pow be changed anytime?


#11

I suspect my solver is close to being optimization free, at least for cpus. Once other people discover and implemented the same ideas (e.g. in contest), then it's a decent memory-bandwidth bound PoW, and there's no obvious reason to toss it out.

I still recommend that Zcash add a second PoW that's memory-latency bound, to both
1) appeal to different hardware that is handicapped on bandwidth but not so much to latency
2) reduce the risk of 51% attacks


#12

Wait, I am sorry. How much faster is your miner compared to an typical Skylake i7 cpu which has some benchmark per thread at 0.03 h/s?

Pretty cool you are able to optimize it by this much, hopefully it is faster than the claimed 10x performance by private GPU miners. Good work!


#13

You can find all the details (at least those I'm willing to disclose) in the thread
"Breaking equihash in Solutions per GB second"