Topic: CPU friendly Altcoin in development - page 5. (Read 8218 times)

It would possibly add some botnet protection too, as users are much more likely to notice a process consuming all their memory.  

exactly!
I made somewhere point on this forum that there should be coin that uses for example 16GB of RAM so that we cant implement this in gpu ?
Or more likely cant do ASICs hmmmm or meaby not

Anyway coin that would require at least 8GB memory would be nice alternative
Based od AES ? (i7 have hardware acceleration) ?

From what I heard scrypt miners use the L3 cache of the GPU/CPU, not the RAM. Could it be possible that if enough memory has to be used the performance difference between GPUs and CPUs disappears?
Also, an algo favoring lots of RAM could be interesting, if one exists.

what are the scrypt default variables?

I'm not a scrypt expert. It's new to me that with the default values it's truly GPU resistant. As far as I understand, it's not that the operations aren't hard to be done by GPUs itself, it's just that enough memory is necessary for a certain scrypt hashing (depending on the used values of course). So with enough RAM a GPU should outperform CPUs like they do it on SHA256, no matter what variable values are used. Correct me if I'm wrong.

Why not use Scrypt as intended.  Scrypt with default variables has beyond horrible performance on GPUs.  Litecoin developers modified it to make it roughly 128x less memory resistant (using only 128KB total).

Generally rolling your own crypto ends badly.

primecoin did this in a way with the early client issues - high-end systems did not outperform $40 CPUs by much. Maybe smuggle in some hard-to-find bottlenecks for the launch.

We are aware of that but it's difficult to truly achieve it. You can't just implement some IP restrictions and think it's done. There is much more about this to do. It's a point for later. First of all we want to get the hash function CPU 'friendly'. Any other 'restrictions' will be included after that.

Some of you like to see an altcoin that is truly GPU,FGPA,ASIC resistant. We would like to see such a coin too so we have started experimenting. We are working on the hashing function right now. It's radix sort based. We use 64 random numbers between 10000 and 75536 (16^4+10k). This 512 char long decimal number is the 'key'. (If we subtract the 10k on each number block and convert it to hex, it's a 256 long hex string in total [or in other words: 1024 bits].) We then change each number block with a specific simple math function and radix sort them by LSD. This gives us a 'hash' (same structure as 'key'). Using a difficulty is already in place. The above explained process for getting a hash out of a key is also depending on the difficulty. The higher the difficulty the more often the hashing has to be done before getting back a hash (simply said). Validating a hash is based on simple math functions depending on the difficulty. The higher the difficulty the less hashes are valid (simply speaking).

I just want to make sure we are on the right track with this.

Possible improvements: I would like to implement tacotime's mentioned tree search algorithm in topic 64239. But it has to be implemented in a way the search is mandatory and that's very hard to do. We may also should use radix sort MSD and LSD instead of LSD only. What do you think?

Do you have any idea what we should change/add to the hashing function?