4 ms·
> proving the memory hardness seems more harduous In fact, several submissions to the Zcash Open Miner Contest, at https://zcashminers.org/submissions https:/
by tromp 10y ago
> proving the memory hardness seems more harduous
In fact, several submissions to the Zcash Open Miner Contest, at
https://zcashminers.org/submissions https://zcashminers.org/submissions
exhibit time-memory tradeoffs that were not considered in that paper, invalidating some of its claims.
My own, memory latency bound, proof-of-work called Cuckoo Cycle
https://github.com/tromp/cuckoo https://github.com/tromp/cuckoo
offers $5000 in bounties for invalidating its claims of near-optimal implementations and trade-off resistence.
- murbard2 10y agoHopefully, in the near future, we can just slap a recursive SNARK on scrypt (or any memory hard hash function for that matter) and call it a day.
- tromp 10y agoWhile building snark proofs is very memory intensive in itself, it is far from optimization free, which is one of the primary requirements for a PoW...
- murbard2 10y agoNot my point. The idea is that you can obtain a cheaply checkable proof that you computed a memory bound function, such as a scrypt hash.
- tromp 10y agoI did get your point. But if the onus to produce such a proof is on the miner before they can broadcast the next block, then the PoW is no longer optimization free.
- murbard2 10y agoAh I see. It's true, but there's a good chance these optimizations would be discovered independently, progressively and percolate into the ecosystem. Turning to ASIC was an "optimization" that was replicated and copied. It's true that there is a lot more secret sauce to optimizing a SNARK, but if mining drives improvement in SNARK efficiency, I would call that a win.
- Ar-Curunir 10y agoThe status quo that SNARKs require a lot of memory is simply due to the current available constructions; optimisations and new constructions will certainly change that.