Reconfigurable hard. Just maximize on what videocards do well, then
   videocards will do best. There's no other way really. The margins just
   get smaller.

   Actually... what if you switch algorithm every x blocks? Max different
   aspects of a default config PC. That way ASICS would have to be PCs!

   So... Maybe we should contact the blender people and them to submit
   renders? Another one is sciencecoins, where you solve science
   questions. The changes in science question will always mess with asics.

   Actually... SETIcoin?

   On May 16, 2014 12:42 AM, "grarpamp" <[1]grarpamp@gmail.com> wrote:

     On Thu, May 15, 2014 at 5:59 PM, coderman <[2]coderman@gmail.com>
     wrote:
     > the other thread mentioned the "ASIC-able" ness of scrypt.
     >
     > what techniques may be used to make scrypt even harder to put on
     die?
     >
     > (is this an arms race between transistor count and algorithm
     tuneables?)
     I've not read much on scrypt. Is there a relation to what
     you see with AMD providing hUMA arch in their APUs
     (Kaveri) where you have CPU and GPU cores being able
     to read/write the same address space, lodge instruction
     queues to each other, and even an ARM core onboard.
     IOW, a merging of formerly hard discrete compute elements
     now on one die and communicating freely, in open commerce,
     would seem to make it harder to design resistant algos
     like scrypt.
     Maybe a next step in hard would be requiring extra nodes,
     a globally minimum latency, checkpointed. We say memory
     hard, storage hard, bit hard, time hard. What other hards
     can we exploit without being fooled. Pheromones?

References

   1. mailto:grarpamp@gmail.com
   2. mailto:coderman@gmail.com