Re: [ANN][MRO] Monero - Anonymous Currency Based on Ring Signatures

Which file in the source code contains the proof-of-work algorithm?

I've tried to locate it and can't seem to find it quickly.

I want to analyze the cpu-only claim.

src/crypto/slow-hash.c

On quick glance, I see AES code. Is this the MemoryCoin algorithm and not the one described in the CryptoNote whitepaper which is memory latency bound?

I do not think it is the memorycoin algorithm.

Analyzed it.

It is employing AES as another means of defeating GPUs (in addition to the memory latency bound), similar to MemoryCoin.

https://cryptonote.org/inside.php#equal-proof-of-work

Quote

3. GPUs may run hundreds of concurrent instances, but they are limited in other ways

See prior analysis of that strategy, which concluded that GPUs would be 2.5 to 3X faster but would perform no better in hashes per Watt:

https://bitcointalk.org/index.php?topic=355532.msg3976656#msg3976656

I pointed out that ASICs would implement AES much more efficiently:

https://bitcointalk.org/index.php?topic=355532.msg3977088#msg3977088

Here follows my conclusions.

slow and thus DDoS prevention will be hampered, which will also likely eliminate any chance of supporting 0 transaction fees
roughly both memory latency and computation bound (instead of the ideal of being only latency bound), thus if Tilera CPUs or GPUs add dedicated AES support or if ASICs are mated to large fast SDRAM caches, the cpu-only claim will fail.
it is not leveraging hyperthreads

In short, it is too computation heavy, not maximizing the CPU's hyperthreads, and thus not only will it not be the best cpu-only PoW algorithm possible, it will also fail to be remain cpu-only if it becomes widely adopted.

Also being computation heavy, it is consuming more electricity than the ideal cpu-only PoW algorithm.

There is another egregious flaw in the proof-of-work algorithm.

AES encryption is being employed as the hash function and assumed to be a random oracle with perfect distribution in order to provide the randomized memory access. Problem is that AES is not suitable as a hash (certainly not when employed as encryption) for it has too small of a output space (repeating patterns will be over a few number of bits), thus it will be possible to attack this with an algorithm to reduce the scratchpad size significantly from the 2MB.