It appears the OP assumes implementing scrypt in hardware is identical in difficulty and development effort to implementing SHA256 in hardware, and that the benefits in hash rate would be similar to SHA256 on GPU's vs. an ASIC...
Not at all. Neither condition is necessary for the point I'm making (well trying to make). See...
In reality, SHA256 is almost a prime example of an embarrassingly simple problem (Google "embarrassingly simple" if you're not familiar with what that term means in the context of parallel processing), and you can pipeline the whole SHA256 calculation and crank out a hash per clock cycle per core. It's almost retardedly simple to develop an SHA256 ASIC, there's even multiple Verilog implementations for FPGA's that you can start with to generate the netlist for the SHA256 cores (at which point the development process diverges from that of FPGA's of course). That's why we've seen several SHA256 ASICs arrive on the market that were designed by novices or people with negligible or no prior VLSI experience.
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.
So, what are we talking here. Let's say $100,000 buys me an extra man-year of engineering time. Let's say it takes 2 man-years, and $200,000 extra.
Preposterous, do you disagree? Nonetheless.
What's that mean to the overall cost of bringing an ASIC miner all the way to retail from scratch? 5% increase? 3% increase? I'm not going to say it's trivial. It's no show stopper.
Implementing scrypt in hardware is not what I'd call "embarrassingly simple" in comparison. A Radeon 69xx (or maybe a 79xx depending how you value power efficiency) die is fairly close to being a pretty good hardware implementation for scrypt. Yeah, you can probably do slightly better in a few areas (but worse in others, particularly if you're stuck interfacing to off-chip GDDR5, as AMD kinda has the edge over anything an amateur-developed ASIC is going to have for a memory controller core(s)).
Oh my god, this is entirely new to me. And absolutely hilarious. If I recall correctly LiteCoin was actually developed for "GPU Resistance". The irony here is "thick as butta".
On topic, you keep talking about amateurs. That was what happened with the original, simple implementation of a blockchain, because "amateurs" were the only ones who cared and it was, as you state, embarrassingly simple.
I know I posted some of this after you but, with the example of BitCoin right in front of them, if a scrypt coin breaks $xx USD (mystery threshold at this time) and holds it for a few months, or shows signs of climbing, the situation is going to be quite different. It won't be about how many years it takes a man, it will be about how many man-years it takes.
... Or else you do on-die SRAM and pick a good spot along the more obvious TMTO curve (lookup gap) and live with burning tons of die area on SRAM. But it's not going to result in something with an epic performance gap compared to GPU's, as happened with SHA256 for BTC.
In my opinion, OP's points would be valid if developing an scrypt ASIC were of equal difficulty and complexity to slapping an array of open-source SHA256 cores through an open-source ASIC router and layout tool and sending off the placed and routed design to the foundry (oversimplification, but not by much). So I would say yes, the algorithm does actually matter. You can spin an SHA256 ASIC design for significantly less than $1M if you do the design work yourself. You can even screw up the design royally several times and re-run new masks through MOSIS (an ASIC prototype aggregation service) multiple times and still be under that amount.
The performance gap doesn't have to be epic, it just has to be significant, and "Burning tons of die area on SRAM" may be exactly what would happen. I'll get back to this in a second. Also a reference back to my comment about your focus on amateurs.
And to bring it further into the clear, I suspect the majority of the difference in cost between producing a scrypt ASIC Miner and a SHA ASIC Miner is going to be in the supporting miner hardware, which is going to require a lot more activity to occur off-chip than bitcoin does.
I'm going to make a statement here that is absolutely outside of my realm of knowledge. It's actually possible that the design, production and fab of a scrypt asic would end up being cheaper than the same process for a SHA ASIC due to this very fact.
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 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).
Maybe people just aren't understanding how dirt simple a hardware implementation of SHA256 really is.. Not exactly ground-breaking technology that demands a cutting-edge process node here.
Back to burning up that die space. What if (yes I'm speculating again, and asking for your input) some basic research or, more likely early prototyping/simulation, were to show that you could do it better by burning the whole damn thing on a single die. Stick with me here. The cost of the die will increase immensely. But your ASIC miner could then consist of a power supply, an I/O interface comparable to a SHA256 asic, if not simpler, and a water (more likely oil) cooler.
An interesting thought. If you care to analyze it I'm interested in what you have to say. If you eliminate so many other factors in the design/development/manufacturing process, it might be worth the increased cost per die. Pile on reliability, life span in the field, and a few other factors. Would you be willing to dismiss this out of hand?
If so, I'd like to know what your experience and/or credentials are before I decide how seriously to take your dismissal.
It takes well under the $8M figure mentioned by the OP to call up AMD and license the Radeon 6950 or 7950 reference design, and produce boards with multiple GPU's on them.
This might be the show stopper. In light of my original point, I want to mention that just because something "isn't the cheapest way" doesn't make it "not economically viable". And it keeping with what I posted after you - the decision to actually create a Scrypt ASIC may be an entirely emotional one, with factors that were nonexistent "when bitcoin did it".
Back to our imaginary billionaire
It depends on what kind of guy he is. If he wakes up and says "I want to pwn crypto" and goes about it as efficiently as possible, he's likely to speak to AMD. If he wakes up and says "I want to be the guy that brought out the scrypt ASIC", all other factors go out the window.
Profit is profit, and if the numbers are big enough, a 1% improvement in over all efficiency (calculated only by coins/joule) may make it "economically viable".
I'm going to make a statement here that is absolutely outside of my realm of knowledge.
There are probably people on this forum who know the real answer to that, I don't.
You're correct on both of these items though.
Good to know I was right about something. You covered some of the same ground in both posts, if you think me shifting quoted blocks to address similar points changed your meaning, let me know.
I'm also glad no one has showed up to tell me about "an ASIC-proof algorithm".
