Why did Ethereum design Ethash instead of using an existing memory-hard hash function?

Question

Ethereum uses the Ethash hash function for proof-of-work. It was designed specifically for this purpose by Vitalik based on previous work by Thaddeus Dryja.

The main rule they teach you in a crypto class is: never roll out your own crypto. Why not take any of the existing memory hard hash functions? From scrypt used in Litecoin and its forks to any of the PHC competition finalists (also, Zcash later chose Equihash, designed by the authors of the PHC winner, for its PoW).

I did not find any academic papers with cryptanalysis of Ethash. This analysis elaborates on why password hashing and PoW are not entirely the same task, but still gives no rationale for designing a new algorithm.

Ethash serves its purpose well for now, but what if a critical vulnerability is found? For a recently developed algorithm without years of cryptanalysis behind it it seems likely compared to more established alternatives.

What was the rationale behind choosing to design a new hash function for Ethereum's PoW?

Answer 1

Though it's only a partial answer, this might shed some light: http://github.com/ethereum/wiki/wiki/Ethash-Design-Rationale . I seem to recall reading a blog post by vbuterin, but I can't locate it at the moment.

The main points can be found in that link, and are as follows:

• IO saturation: The algorithm should consume nearly the entire available memory access bandwidth (this is a strategy toward achieving ASIC resistance, the argument being that commodity RAM, especially in GPUs, is much closer to the theoretical optimum than commodity computing capacity)
• GPU friendliness: We try to make it as easy as possible to mine with GPUs. Targeting CPUs is almost certainly impossible, as potential specialization gains are too great, and there do exist criticisms of CPU-friendly algorithms that they are vulnerable to botnets, so we target GPUs as a compromise.
• Light client verifiability: a light client should be able to verify a round of mining in under 0.01 seconds on a desktop in C, and under 0.1 seconds in Python or Javascript, with at most 1 MB of memory (but exponentially increasing)
• Light client slowdown: the process of running the algorithm with a light client should be much slower than the process with a full client, to the point that the light client algorithm is not an economically viable route toward making a mining implementation, including via specialized hardware.
• Light client fast startup: a light client should be able to become fully operational and able to verify blocks within 40 seconds in Javascript.