scrypt and ASICs

[Lodewijk andré de la porte]

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" <grarpamp at gmail.com> wrote:

> 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?
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 1998 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20140516/3e93d951/attachment-0001.txt>