This may seem a digression but are you currently mining Bitcoin Classic blocks? Are you still involved in that project?
This may seem a digression but are you currently mining Bitcoin Classic blocks? Are you still involved in that project?
Yes, it seems like a digression, and yes, we are still mining Classic blocks. No, I am not otherwise involved in that project. I am generally moving away from Bitcoin.
We already know that a CPU miner can in fact do 10x better than Zcashd - this is almost the case for very slightly tweaked reference implementation of Equihash, as I mentioned in the other thread here: Breaking equihash in Solutions per GB second - #42 by tromp
It is not unexpected that someone actually optimizing this obtained further speedup.
I would support a delay in the launch, but (luckily) I have no say in this, and I suppose there are lots of reasons why Zcash wants to launch on schedule anyway. Hopefully, someone will not care about a potential temporary gold mine so much and will open source an optimized implementation before launch.
2 Likes
Thank you for sharing these figures! If you can easily do so and don’t mind sharing, what performance would you obtain for Zcash’s older 144,5 parameters?
2 Likes
As it has now been clarified on the website, the remaining 10k are expected to be in prizes for the Runners Up - so even if a submission to the Challenge doesn’t win one of the main prizes, it might nevertheless win a smaller prize.
4 Likes
If your GPU implementation is cca 13 times faster than CPU implementation, then the claim from Equihash paper about algorithm resistance seems to be not so solid. The memory speed of GPU is only 2-3 times faster, plus there are no big caches, compared to CPU.
Personally, I feel worried about ZCASH algorithm resistance and consider CPU mining as a loss of money, time and energy. This is unfortunate, as I hoped for similar hashrate per joule using either CPU or GPU.
Does the block validation used by ZCASH implement the “algorithm binding” mentioned in Equihash paper? This should prevent optimizations bypassing K partial sorts.
2 Likes
I have already given up the idea of CPU mining. Going back to Monero.
2 Likes
@jtoomim Congrats on this work. Am I interpreting the numbers correctly? If the 0.58 Sol/s on a single core of the CPU is multiplied by @zawy’s previous 2.84x multiplier for 4 cores, then isn’t this current comparison on these GPU vs. CPU at only a 4.55x GPU increase for these initial findings?
2 Likes
What I call a “typical” CPU (good 2013 desktop, or 2015 non-low-power laptop) is 0.044 S/s aka H/s for 1 core on the benchmark. On the testnet, I got 0.12 S/s for 4 core, 2.74x. These a re 3.2 GHz. Also, that’s a 4 GHz newish chip, and probably using DDR4. So I think the math should go roughly like this:
0.58 / 0.044 x 3.2 / 4 x 1600 / 2150 = 7.85x
Folks: I’m definitely not going to delay the launch due to the existence of proprietary miners that are 100x better than the zcashd miner.
The most important thing, to me, is getting this breakthrough privacy technology into the wild — letting it get out of control. There are a lot of people around the globe who are interested in building Zcash into their businesses and systems. The most important thing is to take the next steps to make that possible.
The next step is the Oct 28 genesis block.
That said, I would love for Zcash mining to be widespread, decentralized, and open. Running the Zcash Open Source Miner Challenge is one way that we — the Zcash Company, with help from our friends at https://LeastAuthority.com — are trying to do that.
Beyond sponsoring the Challenge, though, there’s not much more we can do about this. The community is going to have to figure out how to achieve decentralized mining without the Zcash Company taking the lead on that. Or, if we can’t achieve decentralized mining, will just have to live with mining that is similarly centralized as Ethereum mining is. That’s not the end of the world. Nor of the Zcash project.
3 Likes
R.I.P. CPU 
1 Like
How fantastic would these claims have to be to give pause to doubt them?
1 Like
@Hawkix The Equihash paper claims that the algorithm is bandwidth limited, but makes no justification of that claim. The claim is wrong. If they had done even some simple math, they would have seen that.
As an upper bound if you have poor memory use, and your dataset is <= 1 GiB in size, and you read or write to every byte 10 times in a run, you should be able to get 1.88 solutions for every 10 GiB of data transferred. CPUs typically have around 25 GiB/s of bandwidth, which should limit them to something like 4.7 Sol/s. On a GPU with 320 GiB/s of bandwidth, this would mean something like 68 Sol/s.
@DavidSchargel Our benchmarks are on a $330 CPU vs a $120 GPU. The two programs are using different algorithms. I think the GPU code has more room for improvement than the CPU code. Per dollar, we’re currently at 12.9x better for the GPU, and I expect that number to increase as we optimize more.
@zawy No, it’s DDR3, but bandwidth doesn’t matter. It’s 4.4 GHz though (Turbo boost). I get 9.6x faster clock-for-clock after changing those two parameters.
1 Like
I am wondering the same thing @Hawkix asked: is there anything in the network to validate that solutions meet the “algorithm binding” criterion? It seems to me that discarding that constraint could certainly speed things up quite a bit, so that a couple of miners choosing to ignore that constraint could very easily become 51% of the network.
Yes, the wagner conditions are enforced, of course.
1 Like
But what in the network enforces them?
function bool Equihash<N,K>::IsValidSolution(const eh_HashState& base_state, std::vector soln)
from zcash/equihash.cpp at master · zcash/zcash · GitHub
enforces them…
This is called from bool CheckEquihashSolution(const CBlockHeader *pblock, const CChainParams& params)
in zcash/pow.cpp at master · zcash/zcash · GitHub
3 Likes
Just a PSA to all the people who are building miners, not entering the ‘Open Source Miner Contest’, hoping to make more money by selling privately, and perhaps don’t know a ton about game theory:
Unless your miner would win the contest if you entered it (that is, unless your miner performs strictly better than every entry in the Open Source Mining Contest by the contest’s end) your private miner will be exactly worthless by the contest’s end.
People will not pay a premium for a product that is equal or inferior to a free (as in ‘freedom’ and ‘beer’) product.
So do bear that in mind. If your closed-source miner isn’t the absolute best then you get no return on the time/energy/money you’ve invested so far.
On the other hand, if you do open source your miner and enter it into the contest, you can get a payout even if it isn’t the best performing miner in the contest, because the judging criteria will reward you for any of your ideas that get incorporated into other entrant’s code.
Indeed, due to this ‘cross pollination’ feature of the contest, your best strategy* is actually to open source your miner and enter it in the contest as early as possible, because then anyone else that uses any of the same novel ideas as you will actually be improving your chances of winning.
[*] Unless, of course, you are confident that your closed miner will outperform the contest winner by a nonnegligible margin.
13 Likes
I so fully agree with you @Austin-Williams. I advise private developers to either find an investor right away and secure the payment, or prepare to submit to open source contest ASAP. Later will be too late…
Also, in many countries, 10K$ is a WHOLE LOT of money
2 Likes
What a huge FAIL this turned out to be. GPU miner so far x12 faster than the CPU miner. Why would anyone choose to use Zcash instead of Monero again ?