stslimited (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 23, 2013, 04:49:25 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 23, 2013, 05:07:10 AM |
|
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 (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 23, 2013, 05:12:51 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 23, 2013, 05:23:52 AM |
|
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
Legendary
Offline
Activity: 4480
Merit: 3163
Vile Vixen and Miss Bitcointalk 2021-2023
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 23, 2013, 05:26:07 AM |
|
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).
|
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions!
|
|
|
Revalin
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 23, 2013, 05:31:03 AM |
|
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.
|
War is God's way of teaching Americans geography. --Ambrose Bierce Bitcoin is the Devil's way of teaching geeks economics. --Revalin 165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
|
|
|
Foxpup
Legendary
Offline
Activity: 4480
Merit: 3163
Vile Vixen and Miss Bitcointalk 2021-2023
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 23, 2013, 05:41:29 AM |
|
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.
|
Will pretend to do unspeakable things (while actually eating a taco) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4I am not on the scammers' paradise known as Telegram! Do not believe anyone claiming to be me off-forum without a signed message from the above address! Accept no excuses and make no exceptions!
|
|
|
Nova!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 23, 2013, 07:26:37 AM |
|
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.
|
Donate @ 1LE4D5ERPZ4tumNoYe5GMeB5p9CZ1xKb4V
|
|
|
matthewh3
Legendary
Offline
Activity: 1372
Merit: 1003
|
![](https://bitcointalk.org/Themes/custom1/images/post/question.gif) |
May 23, 2013, 06:24:40 PM |
|
Aren't KNCMiner developing a litecoin FPGA. If you can make a FPGA miner it could hardcode it into an ASIC AFAIK.
|
|
|
|
etotheipi
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 23, 2013, 09:41:26 PM |
|
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
Legendary
Offline
Activity: 2128
Merit: 1073
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 23, 2013, 11:13:02 PM |
|
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/EDRAM2) 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
Legendary
Offline
Activity: 1102
Merit: 1014
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 23, 2013, 11:25:45 PM |
|
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
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 406
Merit: 250
The cryptocoin watcher
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 23, 2013, 11:33:04 PM |
|
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
|
𝖄𝖆𝖈: YF3feU4PNLHrjwa1zV63BcCdWVk5z6DAh5 · 𝕭𝖙𝖈: 12F78M4oaNmyGE5C25ZixarG2Nk6UBEqme Ɏ: "the altcoin for the everyman, where the sweat on one's brow can be used to cool one's overheating CPU" -- theprofileth
|
|
|
GSnak
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 23, 2013, 11:39:24 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 24, 2013, 12:26:09 AM |
|
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.
|
Dans les champs de l'observation le hasard ne favorise que les esprits préparé
|
|
|
ranlo
Legendary
Offline
Activity: 1988
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 24, 2013, 01:23:24 AM |
|
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 (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 24, 2013, 04:10:24 AM |
|
thanks 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
Legendary
Offline
Activity: 1988
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 24, 2013, 08:46:17 AM |
|
thanks 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
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 406
Merit: 250
The cryptocoin watcher
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 24, 2013, 09:12:39 AM |
|
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.
|
𝖄𝖆𝖈: YF3feU4PNLHrjwa1zV63BcCdWVk5z6DAh5 · 𝕭𝖙𝖈: 12F78M4oaNmyGE5C25ZixarG2Nk6UBEqme Ɏ: "the altcoin for the everyman, where the sweat on one's brow can be used to cool one's overheating CPU" -- theprofileth
|
|
|
digitalindustry
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 24, 2013, 11:50:27 AM |
|
thanks 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.
|
- Twitter @Kolin_Quark
|
|
|
|