@Hamsta - głównie miałem na myśli zalety algorytmu Scrypt w porównaniu do do SHA-256. Więc tak ogólnie chodzi nie o to żeby dać nowy algorytm dla którego jeszcze nie ma ASIC, pojawi się ASIC do nowego algorytmu to dać kolejny. W przypadku użycia algorytmu Scrypt chodziło o to żeby algorytm po implementacji sprzętowej nie miał aż takiej przewagi wydajnościowej. Wystarczy porównać nawet różnice między CPU i GPU - w przypadku Scrypt jest dużo mniejsza niż w przypadku SHA256. Duże znaczenie ma tu też że RAM na GPU jest dużo szybszy niż zwykły - gdyby nie to różnica między GPU a CPU w przypadku Scryptu by była dużo mniejsza. W przypadku SHA256 szybkość RAMu nie ma większego znaczenia (przez co można było obniżać mocno taktowanie RAMu żeby oszczędzać prąd). W przypadku SHA256 implementując sprzętowo uzyskało się niskim kosztem bardzo duży przyrost wydajności. W przypadku Scrypt nie tylko że koszt będzie dużo wyższy to przyrost wydajności będzie dużo mniejszy i przez to że nie znajdzie się dużo szybszej pamięci niż jest montowana na GPU i przez to że na krzemie o danej wielkości upcha się mniej równoległych jednostek. I taki był właśnie cel algorytmu Scrypt - spowodować żeby implementacje sprzętowe miały jak najmniejszą przewagę w stosunku do implementacji programowych. W algorytmie Scrypt nie chodziło żeby zwiększyć bezpieczeństwo SHA256 - to jest i będzie odpowiednie - chodziło o mocne zwiększenie zużycia RAMu i właśnie to żeby implementacje sprzętowe miały jak najmniejszą przewagę.
A jeszcze o samym algorytmie Scrypt. Ogólnie polecam przeczytać FIPS 180-4 (dokumentacja algorytmu SHA-256) i przede wszystkim Scrypt Paper - tam jest bardzo fajnie opisane

O samej implementacji tych algorytmów nie będę pisał żeby tu wszystkich nie zanudzić. Więc tak ogólnie - algorytm Scrypt to jest połączenie algorytmu SHA-256 z salsa20 żeby algorytm był bardziej memory hard (lepiej po angielsku bo polskie tłumaczenia są dziwne). Generalnie algorytm memory hard ma wymagać możliwie jak najwięcej pamięci dla danych operacji. Ogranicza to mocno możliwość zrównoleglenia obliczeń - korzyść ze zrównoleglenia jest mała. Sprzętowe implementacje algorytmu nie mają aż tak dużej przewagi w wydajności w porównaniu do implementacji programowych. Dodatkowo koszt implementacji sprzętowej jest dużo wyższy z powodu dużych wymagań pamięciowych - pamięć jest najdroższym z elementów jeżeli chodzi o logikę. Ilość miejsca zajmowanego przez pamięć jest też o wiele większa niż logiki co zmniejsza ilość jednostek którą można upakować na krzemie o danej wielkości. Jest też większa ilość operacji w algorytmie Scrypt niż w SHA256 co też powoduje że na krzemie o danej powierzchni zmieści się mniej równoległych układów (ale to już ma mniejsze znaczenie niż cechy algorytmu memory hard).
Kilka cytatów ze Scrypt Paper:
"Since memory-hard algorithms asymptotically come close to using the most space possible given their running time, and memory is the computationally usable resource general-purpose computers have which is most expensive to reproduce in hardware, we believe that, for any given running time on a sequential general-purpose computer, functions which are sequential memory-hard come close to being the most expensive possible functions to compute in hardware."
"Indeed, it is surprising to consider the effect of adjusting parameters so that a sequential memory-hard function takes twice as long to compute: As long as there is enough random-access memory to compute the function on a general-purpose system, doubling the time spent asymptotically results in the cost of computing the function in hardware increasing four-fold, since the time and required space are both doubled."
"Many general-purpose systems, the CPU and motherboard are more expensive than the
RAM; but the vast majority of that cost is due to the requirements of general-purpose compu-
tation, rapid sequential computation, and support for peripheral devices. The area occupied by
computation logic on modern CPUs is vanishingly small compared to caches, instruction decoding,
out-of-order execution, and I/O."