Quote from: smooth on April 27, 2016, 09:03:06 PM

Quote from: AlexGR on April 27, 2016, 05:48:58 PM

And we also have a "catastrophic" problem with PoW:

No, it you read what I wrote it was a hypothetical, modified version of AES which does not diffuse to all of the output bits, which is specifically not what real AES is designed to do. No one has identified an actual problem.

Ok, let's make it more practical then. Citing the experts below:

Quote from: AnonyMint on May 06, 2014, 05:48:40 PM

Quote from: AnonyMint on May 06, 2014, 11:11:45 AM

Quote from: smooth on May 06, 2014, 09:38:34 AM

Quote from: AnonyMint on May 06, 2014, 09:36:33 AM

Quote from: smooth on May 06, 2014, 09:30:43 AM

Quote from: AnonyMint on May 06, 2014, 09:29:43 AM

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.

Monero #REKT Cry