Quote from: smooth on May 07, 2014, 01:04:37 AM

Quote from: Keyboard-Mash on May 07, 2014, 12:58:47 AM

Quote from: smooth on May 07, 2014, 12:50:30 AM

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

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.

I agree with this. Only a small number of bits of the output of AES are being used, but AES does not guarantee that all of its output bits are random. For example, consider an algorithm AES' which is just like AES except that it appends 10 trailing bits that are always zero (AES'(x) = AES(x) << 10). This would be just as secure as AES for encryption, but catastrophically bad for slow_hash.

I suspect the developers wanted to use AES because of the hardware support in Intel CPUs, but they made a mistake, though it isn't immediately apparent how catastrophic this is (unlike my toy example above for example). If they used a true secure hash, it would be much slower and likely not memory bound.

The algorithm can and should likely be improved in this regard, although I don't have any immediate suggestions how.

What kind of comparison can be made with Tromp's Cuckoo Cycle (Man, that's painful to say -- sorry Tromp), or the blockchain mining style that's proposed in HoneyPenny in light of the weakness in AES?

I dont understand tromp's algorithm well enough to comment. dga posted some cautionary comments that I would echo. I don't have a link for that.

The premise of honeypenny's algorithm seems to be requiring access to the block chain in order to hash. That has some good and bad properties. Given sufficient block chain growth it turns into a storage bound task, since storing the block chain in primary memory seems implausible going forward, and likely tends toward centralization. Perhaps no more so than centralization of nodes though.

I go into detailed discussion with tromp in my thread:

https://bitcointalk.org/index.php?topic=557732.0

Also you can find some discussion between him and myself in the MemoryCoin 2.0 PoW thread which I linked to upthread.

In short, I don't believe it is CPU only currently, but (and I think we agreed this, but ask him) it might be the appropriate algorithm for mobile later if CPUs move to extremely high number of cores. Our discussion concluded with more testing is needed and I would try to help him get a TileGX in future if I can.