scrypt is "memory intensive" therefore no ASICs, but how?

[stslimited]

hello, so at this point everyone can repeat that scrypt is "memory intensive" and therefore no ASICs can be produced for that algorithm because it would cost too much


now that we have established that copypasta, lets talk details:

what kind of RAM and how much would it cost

what are the technical requirements for a theoretical system to be specifically good at hashing with the scrypt algorithm

for benchmarking purposes, 1000 times better at hashing with the scrypt algorithm, since scrypt is supposed to be 1000 more difficult than the SHA-256 standalone algorithm

[Etlase2]

These are very difficult questions to answer. Scrypt is not just a "simple" algorithm that is the same everywhere like SHA-256. It has values that can be changed, and those values can have significant effects on the viability of something like an ASIC. It is also hard to predict how this viability might change over time.

For example, LTC used figures that mistakenly were thought to be GPU-resistant, but they were not. The same could happen regarding ASICs without a deep amount of research. And it could still be wrong.

[stslimited]

These are very difficult questions to answer. Scrypt is not just a "simple" algorithm that is the same everywhere like SHA-256. It has values that can be changed, and those values can have significant effects on the viability of something like an ASIC. It is also hard to predict how this viability might change over time.

For example, LTC used figures that mistakenly were thought to be GPU-resistant, but they were not. The same could happen regarding ASICs without a deep amount of research. And it could still be wrong.

right


this doesnt help me, can you go into more detail about the values and their significant effects?

I understand this is a very new algorithm, but white papers are a little over my head on these things. who can tell me about it in depth (but the formulas using differential equations will need some adequate explaining)

[Etlase2]

I haven't done much research on scrypt so I can't help you there. But neither have many other people around these parts. Scrypt being used as it is for LTC and clones is something new, and there is not much theory behind it--it is still pretty unexplored territory.

[Foxpup]

I do not know why people say a CPU plus a ton of RAM is cheaper and more efficient than an ASIC with exactly the same RAM, but they're wrong. An ASIC can be manufactured to do anything a CPU can do (a CPU is, itself, a type of ASIC after all), and can be made to do it more efficiently by not devoting power or chip real estate to all of the useless tasks a CPU has to be able to do. The only reason we don't have Litecoin ASICs right now is because the market is too small to justify the initial R&D costs. Hell, if I had a few tens of millions of dollars to spare, I'd design one myself just to make the Litecoin people look like idiots (while simultaneously collapsing the Litecoin market completely, since "ASIC-proofness" is its whole claim to fame after it was proved that it was not, in fact, "GPU-proof", as previously claimed).

[Revalin]

Bitcoin is mostly hashing, so most of an ASIC would be SHA256 cores stamped out side by side on the chip.  Such cores are fairly compact.

I'm not a Litecoiner, but I believe they have it set to require 128KiB of memory per core.  That means you have to stamp out (core) (128KiB) (core) (128KiB) across the chip; therefore you get far fewer cores per chip.

The alternative is to have an ASIC with a memory bus to some external DRAM chips.  That makes the RAM cheap but you now have to get a much bigger ASIC for all the bus lines, and you still won't get very many cores on a chip before the RAM speed becomes a bottleneck.

Originally people thought the RAM requirement would prevent GPUs from being useful at all.  That was wrong, but I don't think they can escape the RAM bottleneck generally, so ASICs, like GPUs, will be limited mostly by the RAM you can attach.  That might change if someone can put together an inexpensive ASIC with RAM on die.  I don't expect that to happen faster than the rate GPU-mem-bandwidth-per-dollar increases, but you never know.

I do think LTC was too conservative with their memory size.  They were trying to keep it in L2 cache to keep it targeted at general purpose processors, but I think they would have done better requiring a few hundred megs per core.

[Foxpup]

I do think LTC was too conservative with their memory size.  They were trying to keep it in L2 cache to keep it targeted at general purpose processors, but I think they would have done better requiring a few hundred megs per core.

Nope. That would just put CPUs at a disadvantage compared to an ASIC with a single core and the largest cache that will fit on the die. You can't win.

[Nova!]

Scrypt is resistant because it is memory hard.  
The amount of memory required is controlled specifically by a psuedo randomly generated list that is changed at every hashing cycle.  This means that the setup and take down of the list is expensive and it has to be done with each iteration.  The alternative is to only generate a small subset of it, but the generation algorithm is itself CPU intensive.

The solution to this problem is to have 2 cores  and a metric crapton of on die ram.  
In this design, 1 core runs the prng algo, the other does the hashing.  
They need to coordinate a little with one another, but it is most definitely doable.
It's much, much harder than SHA256 and the hash rate will never be equal to an ASIC running SHA-256, but relative speed ups should theoretically remain the same as we saw in the progression of BitCoin mining.

Nevertheless, LTC can in fact be mined by even single core FPGAs at a much higher rate than with GPUs I estimate 10x to 100x speed up depending on a number of factors including bus speed, on-die ram, internal clock speed etc.
  
Also ASICs can be built from some FPGAs and those ASICs can be still faster.

The trick is to find an FPGA with as much on die memory as possible and then ensure that your implementation takes full advantage of it.

For the record I built an FPGA scrypt miner a few weeks ago.
That particular FPGA has a direct path to ASIC from the mfr because it's designed specifically for prototyping ASICs.

The value of LTC is not high enough at this time to justify the cost of the FPGA and in my case at least, an error in the code that I was using caused it to overheat (I couldn't get temp data out of it, the miner was reading 0 the whole time, it never slowed down and sounded like a jet landing the whole time).  It quickly became a paperweight.  
A $10,000 paperweight.  

Nevertheless I did a lot of work on it in my spare time and I am considering a kickstarter project to fund continued development.
I almost started one until I found out the true cost of the FPGA I managed to toast and realized it was probably out of reach of pretty much everyone including myself.
It would have to come down by an order of magnitude in cost before it would be a financially viable option for most folks.

[matthewh3]

Aren't KNCMiner developing a litecoin FPGA.  If you can make a FPGA miner it could hardcode it into an ASIC AFAIK.

[etotheipi]

I'm actually curious about this myself, having no real experience with ASICs (or much HW, at all). 

I would expect that a implementation of scrypt with static parameters would be possible to implement on an ASIC.  I don't know how Litecoin works, but couldn't it be made so that the parameters are floating?  i.e. The compute time and RAM amount would change as more or less power entered the network, or at least as a function of time.  Perhaps, an ASIC could be made to handle up to 256 MB of RAM, to accommodate future growth, but it wouldn't last forever like the current proof-of-work does.

[2112]

Currently this issue belongs to a class: "those who tell don't know, those who know don't tell". Seems like there is a significant activity and money-making opportunity to produce decent hardware dedicated to scrypt() hashing.

There are however some easy points that allow to easily discover the people who write with no actual knowledge:

1) mentions of DRAM and various DRAM interfacing technologies like DDR, but no mention of eDRAM (embedded DRAM) http://en.wikipedia.org/wiki/EDRAM

2) use of "cache memory" as a supposed requirement of an efficient scrypt() implementation.

Point (1) is somewhat excusable because this technology may be somewhat hidden in the layers of complexity by the ASIC design tools.

Point (2) is a symptom of somebody who likely has no grasp of logic design whatsoever and cannot distinguish between cache tags and cache lines.

Can anyone with longer experience with Bitcoin ecosystem post his guess as to how long did ArtForz mine on the GPUs in private before there were first open-source implementations of the GPU mining? This would be relevant for comparison purposes.

Obviously this is bitcointalk.org; so there is a 3rd class of people: those who know, but intentionally spread disinformation to gain some future advantage.

[weex]

From a high-level, scrypt was designed with the cost of on-die real estate in mind. If you want to fill your die space with memory, it means having less cores and scrypt was designed so this type of trade doesn't help you hash significantly faster. Since it is built on this model, the only way to get better performance is by using smaller nm processes, faster clock speeds or bigger dies.

[bitdwarf]

Browse the YaCoin development thread, especially after page 13. There's a whole lot of discussion on Scrypt's memory requeriments, since YaCoin uses a variable formula.

https://bitcointalk.org/index.php?topic=206577.0

[GSnak]

From a high-level, scrypt was designed with the cost of on-die real estate in mind. If you want to fill your die space with memory, it means having less cores

No one's going to put 2000 cores + 1.6GB RAM on one die. You could design an ASIC specifically for Scrypt and add the fastest DRAM available, but that'd essentially be a video card.

[jimhsu]

Browse the YaCoin development thread, especially after page 13. There's a whole lot of discussion on Scrypt's memory requeriments, since YaCoin uses a variable formula.

https://bitcointalk.org/index.php?topic=206577.0

If anything, that coin is going to be the best real-life experiment to determine what exactly is the best N value for a possible future Litecoin2.

[ranlo]

It quickly became a paperweight.  
A $10,000 paperweight.  

That sucks, but it must have been cool to create something like that. Sure, it had a flaw, but still. I'd love to have the hardware knowledge to handle creating new things.

[stslimited]

thanks

Browse the YaCoin development thread, especially after page 13. There's a whole lot of discussion on Scrypt's memory requeriments, since YaCoin uses a variable formula.

https://bitcointalk.org/index.php?topic=206577.0

so, great. This thread does reveal that it is possible

I would be willing to crowdsource or do a public offering of shares to support an endeavor. Everyone keeps talking about how much money it would, obvious solution is to pool resources for R&D

try not to 51% litecoin in the process

[ranlo]

thanks

Browse the YaCoin development thread, especially after page 13. There's a whole lot of discussion on Scrypt's memory requeriments, since YaCoin uses a variable formula.

https://bitcointalk.org/index.php?topic=206577.0

so, great. This thread does reveal that it is possible

I would be willing to crowdsource or do a public offering of shares to support an endeavor. Everyone keeps talking about how much money it would, obvious solution is to pool resources for R&D

try not to 51% litecoin in the process

I'm kind of iffy on this. While I think it could work out to be a good thing, it could also end up in a wash.

[bitdwarf]

so, great. This thread does reveal that it is possible

I would be willing to crowdsource or do a public offering of shares to support an endeavor. Everyone keeps talking about how much money it would, obvious solution is to pool resources for R&D

Easiest thing to do would be to support YaCoin, so we have a real life test of high-Nfactor scrypt's GPU-proofness.

[digitalindustry]

thanks

Browse the YaCoin development thread, especially after page 13. There's a whole lot of discussion on Scrypt's memory requeriments, since YaCoin uses a variable formula.

https://bitcointalk.org/index.php?topic=206577.0

so, great. This thread does reveal that it is possible

I would be willing to crowdsource or do a public offering of shares to support an endeavor. Everyone keeps talking about how much money it would, obvious solution is to pool resources for R&D

try not to 51% litecoin in the process

ha ha not a lot of people mentioned the Salsa function and how it relates to memory BANDWITH, you need to talk to Taco and the two guys putting together the FPGA, it’s not that it cannot be done, it’s just that the cost of the high bandwidth memory - or by the time you parallel up the memory to gain the bandwidth, your cost # ratio leaves you with a net power saving,and that's about it .

You may over time, have a device that is better in the long run because it is more power efficient, but nothing like a SHA-256 ASIC as far as multiple of cost # ratio , two companies are working on FPGA – one has a working device – the others are looking to release 3rd quarter , watch and see what they do .

This is generally looked on as a good thing.