I've got an other question.
Does anybody know or has a link where I can find all of the coins that use 'equihash'. Im thinking of buying another mining contract over at Genesis. Because my Dash and the Lights are doing pretty well.
Or should I buy an Ether contract or a Monero contract?
I would love to hear from you guys
Greetz,
Topic: Zcash Equihash PoW Released (Read 7763 times)
Zcash just announced their Open Source Miner Contest
https://z.cash/blog/announcing-miner-contest.html
Does a $30k prize fund tempt you into entering?
https://z.cash/blog/announcing-miner-contest.html
Does a $30k prize fund tempt you into entering?
i think wolfo will win this lol, he is a great dev in programming for mining, but there should be already a testnet version out there, pc only? so it's only a matter of time before there is a porting for the gpu world
None of that is particularly important from an algorithmic standpoint.
Right you are; I managed to implement some substantial optimizations for Equihash; see
https://forum.z.cash/t/breaking-equihash-in-solutions-per-gb-second/1995
Zcash just announced their Open Source Miner Contest
https://z.cash/blog/announcing-miner-contest.html
Does a $30k prize fund tempt you into entering?
https://z.cash/blog/announcing-miner-contest.html
Does a $30k prize fund tempt you into entering?
dga or tromp, any desire to make 1 BTC and help jl777?
https://bitcointalksearch.org/topic/m.15334660
I haven't taken the time to digest Equihash well enough to articulate an algorithm in pseudo-code.
I realize 1 BTC is probably insufficient for your time.
P.S. I am not involved in that in any way other than being aware that jl777 wants it.
I will donate some money to the guy who makes a GPU-based miner for Zcash.https://bitcointalksearch.org/topic/m.15334660
I haven't taken the time to digest Equihash well enough to articulate an algorithm in pseudo-code.
I realize 1 BTC is probably insufficient for your time.
P.S. I am not involved in that in any way other than being aware that jl777 wants it.
It was said in their forum that there still could be changes in their algorithm. Nothing was specifically said what they were. So it would be safe to wait and let everything be finalized before committing in something. You can only mine in their testnet now and the official release has been pushed back with no date mentioned.
dga or tromp, any desire to make 1 BTC and help jl777?
https://bitcointalksearch.org/topic/m.15334660
I haven't taken the time to digest Equihash well enough to articulate an algorithm in pseudo-code.
I realize 1 BTC is probably insufficient for your time.
P.S. I am not involved in that in any way other than being aware that jl777 wants it.
I will donate some money to the guy who makes a GPU-based miner for Zcash. https://bitcointalksearch.org/topic/m.15334660
I haven't taken the time to digest Equihash well enough to articulate an algorithm in pseudo-code.
I realize 1 BTC is probably insufficient for your time.
P.S. I am not involved in that in any way other than being aware that jl777 wants it.
dga or tromp, any desire to make 1 BTC and help jl777?
https://bitcointalksearch.org/topic/m.15334660
I haven't taken the time to digest Equihash well enough to articulate an algorithm in pseudo-code.
I realize 1 BTC is probably insufficient for your time.
P.S. I am not involved in that in any way other than being aware that jl777 wants it.
https://bitcointalksearch.org/topic/m.15334660
I haven't taken the time to digest Equihash well enough to articulate an algorithm in pseudo-code.
I realize 1 BTC is probably insufficient for your time.
P.S. I am not involved in that in any way other than being aware that jl777 wants it.
Again, we must wait to see the final parameters and optimized implementations. It seems likely they'll pick
n=144 and k=5, which means they need to find collisions on 16 bits at a time. That is just a lookup in a 64K entry table;
I don't expect to see any real sorting there. It's less clear how the actual items are represented, and if they are moved
themselves, or by pointer.
n=144 and k=5, which means they need to find collisions on 16 bits at a time. That is just a lookup in a 64K entry table;
I don't expect to see any real sorting there. It's less clear how the actual items are represented, and if they are moved
themselves, or by pointer.
I believe you have the constants wrong. n=144, k=5 means that they're finding collisions
on n/(k+1) = n/6 = 24 bits at a time, repeated 4 times, and then finding final collisions
on the remaining 144-(4*24) = 48 bits, each time from a set of approximately 2^25
candidate hashes.
You're right; I somehow managed to mess up a trivial calculation. Thanks for the correction.
Quote
It's quite intriguing algorithmically. I think the original paper might be a little too glib about the constants, though.
Which constants are you referring to?
Btw, nice to see you back after a 10 month hiatus...
Thanks! I'm not really back - still enjoying the heck out of my sabbatical, but I got curious about this
one this weekend.
The constants: I think they're thinking about the design a bit wrong and should be able to get the
peak tuple length down to 150 bits, or about 600MB, plus perhaps another ~50MB of ancillary
data structures, without incurring more than a constant number of additional hash calculations.
But I could be wrong - I'm just handwaving in my head about how I'd solve it and haven't
tried writing it down carefully. That wouldn't substantially change their view of their memory
use.
I think they slightly overcount (again, small things - maybe 20%) the number of rows that
need to be sorted in main memory, because they're ignoring some of the things that can
hit in L3 cache. As above, though, it's a minor difference.
As others already noted, their analysis ignores HBM / stacked DRAM, which, unlike last year,
is now distinctly real (though still expensive).
None of that is particularly important from an algorithmic standpoint.
Again, we must wait to see the final parameters and optimized implementations. It seems likely they'll pick
n=144 and k=5, which means they need to find collisions on 16 bits at a time. That is just a lookup in a 64K entry table;
I don't expect to see any real sorting there. It's less clear how the actual items are represented, and if they are moved
themselves, or by pointer.
n=144 and k=5, which means they need to find collisions on 16 bits at a time. That is just a lookup in a 64K entry table;
I don't expect to see any real sorting there. It's less clear how the actual items are represented, and if they are moved
themselves, or by pointer.
I believe you have the constants wrong. n=144, k=5 means that they're finding collisions
on n/(k+1) = n/6 = 24 bits at a time, repeated 4 times, and then finding final collisions
on the remaining 144-(4*24) = 48 bits, each time from a set of approximately 2^25
candidate hashes.
You're right; I somehow managed to mess up a trivial calculation. Thanks for the correction.
Quote
It's quite intriguing algorithmically. I think the original paper might be a little too glib about the constants, though.
Which constants are you referring to?
Btw, nice to see you back after a 10 month hiatus...
Again, we must wait to see the final parameters and optimized implementations. It seems likely they'll pick
n=144 and k=5, which means they need to find collisions on 16 bits at a time. That is just a lookup in a 64K entry table;
I don't expect to see any real sorting there. It's less clear how the actual items are represented, and if they are moved
themselves, or by pointer.
n=144 and k=5, which means they need to find collisions on 16 bits at a time. That is just a lookup in a 64K entry table;
I don't expect to see any real sorting there. It's less clear how the actual items are represented, and if they are moved
themselves, or by pointer.
I believe you have the constants wrong. n=144, k=5 means that they're finding collisions
on n/(k+1) = n/6 = 24 bits at a time, repeated 4 times, and then finding final collisions
on the remaining 144-(4*24) = 48 bits, each time from a set of approximately 2^25
candidate hashes.
It's quite intriguing algorithmically. I think the original paper might be a little too glib about the constants, though.
So can we mine this already?
Not for real.
You can mine on the zcash testnet but the current "basic" solver is un-optimized (hence rather slow)
and uses reduced parameters.
I tried to look at the zcash C++ code, but it is C++...
Ideally some comparable reference implementation in C would be really helpful
I thought Wagner's algorithm sorted. I'll have to reread the paper more carefully.
That puzzled me too. I don't see a need for sorting, just for binning to find collisions on the next chunk of n/(k+1) bits
In this case it turns out there is little difference between fully sorting and sorting into bins,
since the expected bin size is only 2 :-)
So equihash really seems to be all about sorting...
I apologize for my ignorance in understanding exactly what you're saying.
The bottleneck is going to be sorting - so it will be transfer speed between the ram and the processor and the processor speed. Not the amount of RAM that will be the bottleneck?
So can we mine this already?
Not for real.
You can mine on the zcash testnet but the current "basic" solver is un-optimized (hence rather slow)
and uses reduced parameters.
So can we mine this already?
I thought Wagner's algorithm sorted. I'll have to reread the paper more carefully.
That puzzled me too. I don't see a need for sorting, just for binning to find collisions on the next chunk of n/(k+1) bits
In this case it turns out there is little difference between fully sorting and sorting into bins,
since the expected bin size is only 2 :-)
So equihash really seems to be all about sorting...
Can someone explain to me the likely difference between a 4GB GPU vs an 8GB GPU? I'm thinking about adding a few GPU's to my farm - the R9 390 has GB of ram which is pretty much useless when it comes to what was supposed to be memory hard PoW (Ethereum). The newer larger memory bandwidth 4GB cards (Nano, Fury, etc) have a better hashrate.
Is more RAM per GPU going to wind up meaning better performance (allow more threads)? Or will optimizations likely allow trading performance + bandwidth for RAM resulting in better performance from a newer lower ram
Is more RAM per GPU going to wind up meaning better performance (allow more threads)? Or will optimizations likely allow trading performance + bandwidth for RAM resulting in better performance from a newer lower ram
The performance between the 4 and 8GB cards are similar. But when the DAG size increases furhter, you will see the difference.
wtf you guys need Zcash for? don`t you know yet that Vcash solved all bitcoin problems already? 
It's a proof of stake coin. Someone hacks Poloniex and coin instantly dies. Many wow.
wtf you guys need Zcash for? don`t you know yet that Vcash solved all bitcoin problems already?
Can someone explain to me the likely difference between a 4GB GPU vs an 8GB GPU? I'm thinking about adding a few GPU's to my farm - the R9 390 has GB of ram which is pretty much useless when it comes to what was supposed to be memory hard PoW (Ethereum). The newer larger memory bandwidth 4GB cards (Nano, Fury, etc) have a better hashrate.
Is more RAM per GPU going to wind up meaning better performance (allow more threads)? Or will optimizations likely allow trading performance + bandwidth for RAM resulting in better performance from a newer lower ram
Is more RAM per GPU going to wind up meaning better performance (allow more threads)? Or will optimizations likely allow trading performance + bandwidth for RAM resulting in better performance from a newer lower ram
Jump to: