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