Hi all, just wanted to know why the Open Source Miner Challenge specifies that solutions should handle a range of Equihash parameters. As far as I can tell Zcash itself uses N=200,K=9.
Why does N=144,K=5 need to be handled? I imagine that writing code that does not handle a range of parameters people can write much more optimised code.
I think there’s still a chance that the final parameters aren’t decided. As for being optimised, it would be a mistake to create an Equihash solver that was incapable of or difficult to adapt to different parameters.
Zcash wants the PoW to have a memory footprint close to 1GB,
but feared the originally planned (144,5) taking too long to solve.
They thought (200,9) should take over 500MB, but didn’t foresee (and neither did the Equihash authors) the recent solvers that can use as little as 128MB to solve (200,9) with no slowdown.
Realizing that (144,5) doesn’t take that long to solve after all (mere seconds), they strongly consider a return to these parameters after launch.
This is very interesting information. Thanks for clarifying!
By “after launch” do you mean at the time of launch or do you mean at some unspecified time after launch? Would the latter require a hard fork or just a soft one?
I don’t expect a parameter change until at least several months after launch, and yes, that would definitely be a hard-fork.
We already intend to alter the mining PoW. See our latest blog post (as well as every other post we’ve made about the Zcash PoW):
Note that because our desired mining goals are best-aligned with general-purpose hardware, a hard-fork to different parameters is a much easier change than from a PoW that has a lot of sunk cost in specific mining hardware (like Bitcoin’s double-SHA256).
didn’t foresee (and neither did the Equihash authors) the recent solvers that can use as little as 128MB to solve (200,9) with no slowdown
… nor did they or the Equihash authors forsee the production of Equihash ASICs on DRAM foundry lines.
Is that happening? Can you provide a reference?