Something seems to be wrong.

https://explorer.zcha.in/accounts/t3Vz22vK5z2LcKEdg16Yv4FFneEL1zg9ojd   22.257749999999994 ZEC

CPU solving us highly memory and clock frequency bound and doesn't scale with cores well at all.

Even so, QCs cannot do preimage attacks on hashes, they can only brute force them faster. For mining, that just means that the difficulty will increase and blocks will stay the same. For addresses, that means that they still cannot find the associated public key because they still can't find the preimage.

That is good. More information.

Crowdfund for open-sourcing tromp’s solvers / funding Cuckoo Cycle
...

Why aren't you joining the open source miner contest?

I would gladly pay a dev fee to have access to a gpu miner. The sooner the better.

also why this coin is not known?

I'm guessing that with the sprint towards October 28th you don't have a whole lot of bandwidth to think hard about this, but if you do come across a reason why waiting until the end to prune duplicates doesn't work, or conclude that it does, a quick post here would be much appreciated.

Maybe when @tromp becomes a ZEC-billionaire next month he'll publish one

Hello folks, this thread appears to be the place with the highest concentration of zECQuihash optimization gurus.  May I trouble you with a stupid question?


I'm trying to correlate that with the zcashd implementation, since it's the only available working cross-checker (too bad it is written for speed instead of readability).  The only part that has me confused is the need to eliminate entries whose index sets contain duplicate/repeated entries after EVERY one of the k collision steps.  There is no mention of this in the algorithm given in the Equihash paper.

I understand why these can't be part of the final solution (the X_i's must use distinct i's).  But why not wait until the end to drop these superfluous solutions?  Why check for duplicates k times?  I did some quick back-of-the-envelope calculations and I'm having a hard time believing that leaving these entries in the table would significantly increase memory consumption.  If you had a duplicate X_a in the second level of the collision, it would have to be a result of (X_a*X_b) colliding with (X_a*X_c) on the first 40 bits (where X_a collides with each of X_b and X_c on the first 20 bits).  If this is true then

 ((X_a*X_b)*(X_a*X_c)) = 00000000000000000000 00000000000000000000

and therefore

 (X_a*X_a*X_b*X_c) = 00000000000000000000 00000000000000000000

so

 (X_b*X_c) = 00000000000000000000 00000000000000000000

and moreover

 (X_a*X_b) = 00000000000000000000 ....................

 (X_a*X_c) = 00000000000000000000 ....................

In general it seems like repeated indices arise in the Equihash-constrained variant of Wagners algorithm as a result of an "overcollision" -- when two rows of the table collide not just on the current column but the next one as well.  When this happens the members of the overcollided set will generate one suprious entry in the next round for every entry they collide with in the current round.  It seems like that would happen on average twice per column.  Is that really enough to bloat the memory usage in a noticable way for k=10?  Surely for something like k=100 we'd be talking about serious combinatorial explosion, but for k=10 there just aren't that many steps compared to the size of the table.

 When I'm done writing a GPU implementation, I'll be quoting performance in solutions/second.

Sol/s and Sol/(GiB•s) are two distinct metrics. Both are important.

As for space for indexes, 21 bits isn't that significant.  After the first sort round, you need 2*21 bits + 180 bits hash = 222 bits.  After the 2nd round, you need 4*21 bits + 160 bits hash = 244 bits, which fits nicely in 32-byte fixed size records.  By the 3rd round the size of the indexes overtakes the hash size, but the number of hashes diminishes.

edit: here's a paper by DJB that discusses optimizing Wagner's algorithm.

Your statement: "That gives it an estimated single-threaded time*space performance of 0.063 S/s / 0.54GB ~ 0.12 S/GBs"
If it doesn't scale with memory, then it was nonsense to include the memory use in GB as a multiplier in performance.

The hashes themselves only take 50MB, so 128MB is not an unreasonable target.  After the first sort, you only need to keep 200-20=180 bits/hash + 21-bits of index per entry, since you only care about those that collide on the first 20 bits.

I think you are making a mistake assuming the performance scales with available memory.

I'm confident I can get the memory requirements at k=9, n=200 down to 128MB. 

there is an algo that is incredibly RAM intensive

https://www.internetsociety.org/sites/default/files/blogs-media/equihash-asymmetric-proof-of-work-based-generalized-birthday-problem.pdf

"Our solution is practical and ready to deploy: a reference implementation of a proof-of-work requiring 700 MB of RAM runs in 30 seconds on a 1.8 GHz CPU, increases the computations by the factor of 1000 if memory is halved, and presents a proof of just 120 bytes long."

It's a little early to be developing GPU miners given that the CPU miner is still being optimized,
and is lacking important features like multi-threading.

Once the CPU miner looks reasonably optimized, I might try my hand at a CUDA version.

None of that is particularly important from an algorithmic standpoint.

http://monerobechmarks.byethost5.com/