scrypt and ASICs

[grarpamp]

On Thu, May 15, 2014 at 5:59 PM, coderman <coderman at 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?