Earlier quoted context omitted.
The best you could hope for in an alternative proof-of-work scheme is a shift from dominating electricity costs and rapid hardware obsolescence to use of commodity hardware, dominated by memory latency instead of computation. That's what my Cuckoo Cycle PoW scheme aims for... https://github.com/tromp/cuckoo On the other hand, some people argue that reducing waste is counterproductive as it also lowers the cost of a h…
How is Ethash compute intensive relative to Cuckoo Cycle? EDIT: Ethash does 1 SHA3 at the beginning, 1 SHA3 at the end, and 64 rounds of FNV1-32 x 32. Verification considers the intermediate digest, so really 1 SHA3 to verify. You do more SHA3 rounds if you don't store the dataset, but this is a memory trap-door (and would require ignoring the mixDigest); the verification cost is still negligible. In our mining pools…
p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
newdata = []
for j in range(MIX_BYTES / HASH_BYTES):
newdata.extend(dataset_lookup(p + j))
mix = map(fnv, mix, newdata)
I admit this doesn't look much more involved than Cuckoo's single siphash-2-4, but perhaps we can measure it. How much faster does this run if you leave out the actual memory access. i.e. replace dataset_lookup(p + j) by (p+j)?In Cuckoo Cycle's case, avoiding the memory lookups reduces runtime by a factor 3.