"ASIC- Proof"

[weav]

(though they may not do any better.)

That was my point.

[1715370746]

1715370746

[1715370746]

1715370746

[1715370746]

1715370746

[1715370746]

1715370746

[digitalindustry]

(though they may not do any better.)

That was my point.

i agree.

[HuuHachu]

Well ... GPU are good at scrypt because of their multiple computation units and their extremely high performance memory (the best we can do today for a "reasonable" size/price ratio.
Could a specifically designed ASIC be better than GPU ? Sure, of course, especially as GPU embark a lot of things not used for scrypt ... But it may not be a lot faster, more probably much more energy efficient.

Also, litecoin scrypt is designed to use memory, but not THAT much ... ~128KB per core (which can be further reduced if using some lookup gap). It was designed to fit in CPU L1/L2 cache.

If you go YACoin way (when N is large), with a memory limited to a few gigabytes, the number of usable cores drops significantly. But GPU are still much better than CPU because they have access to the best (still reasonably cheap) memory that we can make today.

If you want to make ASICs for scrypt (and especially flavours using more memory per core), you will essentially have to find a better memory than the one GPU makers use ... good luck to be profitable ^^ EDIT: Also, even going for sram, i'm not sure the speedup would be that great ... access latency of GDDR may be greater than sram, but this already can be masked significantly by multi-threading.



Last but not least, to explicitly give an answer to the first post : YES, IT IS POSSIBLE to design a coin to be mining-ASIC resistant ... The algorithm just has to change significantly at regular intervals (a few months should be more than enough). If every time some "hard to implement" features are randomly chosen for the next period, there is not much you can do except to go for circuits such as CPU and possibly GPU.

[mubit]

The fact that there is no ASIC like device when the market cap is fairly low is proof that the reverse feedback systems built by satoshi work, as soon as its worth building, it will be built.  This 'resistance' is built into all coins.

This doesn't change the fact that when it becomes viable to produce such devices, the performance gains will (I assume) not be as noticeable.  Hence the term resistant.

[ecliptic]

Based on the rapidly balooning hashrate for litecoin, and the facts that

1. 95% of GPU miners switched to litecoin weeks if not months ago (as it has _LONG_ been more profitable than BTC for GPU miners)
2. Only a complete idiot would continue buying GPUs to mine anything

it's possible that someone has developed an FPGA or ASIC for mining scrypt coins, but is adding hashrate in such a way as to disguise this fact.  It doesn't make $/kWh to buy GPU miners for scrypt coins anymore.

Completely untrue at current profitability rates.  At current rates, mining LTC, a GPU will pay for itself in about 6.5 months.

Since people aren't exactly rushing out to buy GPU's at the moment and ASICS is a remote risk, we can expect the LTC network to stay at about the same hash rate / difficulty for an extended period of time more than sufficient to recoup any initial investment.

And GPU mining profit is WAY above the power cost.  Just run a calculator:

https://give-me-ltc.com/calc

Just absurd to suggest that, at current levels, LTC mining won't pay for the power.  Prove your claim.  And if true, why is 20 gh/s being thrown at LTC and clones ?

As for ASICS, good luck with your BFL pre-order #2,124,123.  Have fun mining with that once it arrives in 2040.  And for FPGA BTC mining good luck competing against the ASICS that have shipped and the hordes of them being run by the manufacturers for easy mining profit

You forgot to double your electricity costs in summer


Diff going above 1000.

Asics/FPGAs for scyrpt CONFIRMED.

TRUEFACTS:

2000 khash/sec
1200 Watts
1000 Difficulty AND RISING RAPIDLY.
0.12 c/kWh x 2 (Cost to remove heat!)
2.62$/LTC  AND DROPPING QUICKLY

Profit is less than 1$/day and when you double elctricty costs YOU'RE LOSING 3$/DAY

Now to watch all the """"'unused"""""" 5xxx and 7xxx GPUs hit ebay and see the price of a 7970 hit 80$ used.

[kramble]

Partially correct on the first point above, and very wrong on the last point.  I'm not sure how you got from "scrypt will require more complicated off-chip support components" to "an scrypt ASIC would could end up being cheaper" than an SHA256 ASIC.  The die area needed to implement an scrypt core (that actually performs with any sort of noteworthy hash rate) is massively larger than for a simple pipelined SHA256(SHA256()) core, regardless of whether there is off-die memory.  And interfacing to external high-speed I/O is one of the hardest things you can deal with in an ASIC design, especially if we're talking about interfacing to something like a very wide bank of GDDR5 at anything close to the clock rates that the Radeon GPU's operate at.  It is, perhaps, very foolish to suggest that addressing an extremely difficult external I/O problem will drive down the cost of developing and fabricating an ASIC, compared with a simple SHA256 core that barely needs to talk to anything (and when it does, can do so over even a dirt simple open-collector bus that just communicates a winning nonce when one is found).

When it comes to development cost, there's also a massive spread.  You can go and pick yourself up an SHA256 core design, for free, that performs fairly well and is fully pipelined, from multiple sources.  For scrypt, you have to go it alone and develop it from scratch, and you end up with an almost infinitely more complex netlist than an SHA256 core (in fact, an scrypt core will tend to contain two SHA256 cores) that is significantly harder to place and route on the die, and much harder to verify gate-level simulations prior to taping out the masks.  The challenge in making an SHA256 ASIC pretty much amounts to placing and routing a fairly simple netlist against the foundry's provided logic cell library, and then just copy'n'pasting the core all over the available die area.  The challenge with scrypt is monumental in comparison.

Just nitpicking (and I know you're far more experienced in logic design than I am), but SHA256 is almost irrelevant for scrypt, The real issue is the salsa-mix, which is designed to be memory-intensive and highly resistant to pipelining. The PBKDF2_SHA256 operations are just a wrapper around the meat of the algorithm.

[defaced]

I'm having this problem:



I just want to point out that there is no such thing as an "ASIC Proof" algorithm.

I also want to point out that there's no such thing as an "ASIC-Resistant" algorithm.

While I'm at it I'm going to go ahead and point out that THIS:



Is NOT an asic.

Now for those of you that are crapping yourselves right now and about to flip out and call me crazy, I'll clarify.

That black box is a special purpose computing device, that uses 1 or more ASICs to achieve it's goal.

These:


are ASICs.

Now anybody that wants to argue that there can be an ASIC-Proof algorithm that a general purpose processor such as an i7 can compute just needs to put on an idiot hat and go sit in the corner.  Yes, I know that's rude as hell but, c'mon.

ASIC Resistance is a real condition, but it has ABSOLUTELY NOTHING TO DO with the encryption algorithm in use.

It's simply an economic situation, and it's fluid.

Litecoin (and other coins) are not ASIC-Resistant in any inherent fashion, and they're certainly not using "ASIC-Resistant Alogrithms".  They're just not currently worth the bother.

If you are backing a coin because you think it is "ASIC Resistant" you're going to learn that this is a self-defeating goal when that coin actually achieves any significant real world use.

I just wanted to make a separate thread for this because there are SO MANY THREADS that I want to post it in. I hope that someone out there feels helped by this explanation.

Whew, all right fit over - Carry on.

You sir are a CryptoKnight +100 for this post.

[aspect]

I would like to refer you to this post: https://forum.litecoin.net/index.php/topic,2702.msg30526.html#msg30526

Please study this specific post as it contains a lot of relevant information on the topic.

[WindMaster]

Just nitpicking (and I know you're far more experienced in logic design than I am), but SHA256 is almost irrelevant for scrypt, The real issue is the salsa-mix, which is designed to be memory-intensive and highly resistant to pipelining. The PBKDF2_SHA256 operations are just a wrapper around the meat of the algorithm.

I'm going to nitpick your nitpick of my post.  Where is the error in my mention that you have to perform SHA256 in the process of calculating an scrypt hash and checking the resulting difficulty?  Yes, we're all aware that salsa20/8 will consume the most logic area and/or take the most time to perform.  That's the very point I was making, that SHA256 is dirt simple to accomplish in an ASIC, while salsa20/8 is not dirt simple to accomplish in an ASIC.  But you still have to take it all the way through (PBKDF2_SHA256 and all) if you're going to see if your hash met the difficulty criteria, so you're still going to need SHA256 implemented.

You weren't able to avoid including an SHA256 implementation in your Litecoin FPGA miner, right?  A quick look at your Github repository shows that a Verilog implementation of SHA256 is indeed present in your source.  

[peonminer]

blahblahblah

[WindMaster]

I would like to refer you to this post: https://forum.litecoin.net/index.php/topic,2702.msg30526.html#msg30526

Please study this specific post as it contains a lot of relevant information on the topic.

Unfortunately, that post also contains some significant errors even in the basic explanation of how scrypt works.  If that post's explanation were correct, it would not be possible to store less than the full 128kB buffer and exploit the obvious TMTO (which mtrlt nicknamed "lookup gap", which is a term anyone mining Litecoin with GPU's will probably recognize).  Every GPU scrypt miner exploits exactly that TMTO to speed up the process by not storing the full 128kB.

[kramble]

I'm going to nitpick your nitpick of my post.  Where is the error in my mention that you have to perform SHA256 in the process of calculating an scrypt hash and checking the resulting difficulty?  Yes, we're all aware that salsa20/8 will consume the most logic area and/or take the most time to perform.  That's the very point I was making, that SHA256 is dirt simple to accomplish in an ASIC, while salsa20/8 is not dirt simple to accomplish in an ASIC.  But you still have to take it all the way through (PBKDF2_SHA256 and all) if you're going to see if your hash met the difficulty criteria, so you're still going to need SHA256 implemented.

You weren't able to avoid including an SHA256 implementation in your Litecoin FPGA miner, right?  A quick look at your Github repository shows that a Verilog implementation of SHA256 is indeed present in your source.  

I completely agree with you. I think I failed to explain myself properly (it was getting late). I just picked up on your "an scrypt core will tend to contain two SHA256 cores" and thought, well mine doesn't! It just got the one SHA256 engine (and a slow 64 cycle one at that) that is used for all of the PBKDF2 operations, and it isn't even remotely stressed (of the roughly 229k 23k clock cycles per hash only around 13k 1.3k are spent on PBKDF2_SHA256, and even those are done in parallel with the salsa so do not affect the overall throughput). [EDIT] OOPS I was thinking in nS steps of simulation (using an arbitrary 10nS clock cycle, the real circuit runs at 25MHz).

I was just looking for an excuse to bump the thread and get some visibility for my github code as feedback has been woefully slow to date (yeah, I know its amateurish stuff, but I'm looking for tips from the pro's so as to improve it, though I fully understand that there is only very limited scope due to the design goals of the scrypt algorithm). Your comments have been very helpful, many thanks for your input  

[usahero]

Someone is wrong on the internet. But I won't waste time explaining into depths.



Asic resistance of the scrypt is compared to how much memory would you need to crack 6,7,8+ lenght passwords. You need a lot of memory to crack 8+ lenght passwords. So much memory, that it is not viable option at this moment.


But that does not mean, that you can't make asic chips that would be 10-100 times faster than gpu's at the moment. Memory price has insignificant role in this. You can buy 4GB very fast ram for 20$. Where do you see problem in ram prices?

I believe no Scrypt asics are there just because the process to create chips cost too much. TMSC will not create you chips for 1000$ :p

[digitalindustry]

So whens this fire sale of these 7950's beginning ?? , i can only see the price rising - ?

i think the only time they will be dumped is when they are no longer useful in the whole market - i.e when we see a sCrypt ASIC , and only after they are readily available.   

[markm]

and a prime numbers ASIC and all kinds more special purpose ASICs.

It might make sense actually if you happen to be a huge multinational corp launching a coin to build your own special ASICs first then launch the coin.

Like playstationcoin or xboxcoin or whatever, mined by a special chip inside the box...

-MarkM-

[dego]

That black box is not an ASIC, it's an ASIC Miner.

That means a miner filled with ASICS.

I think it's just a black box.. maybe, if you are lucky, it gets filled with ASCS during the next few years... dpeending of your order number and of the supplies of PSUs.