Topic: Scrypt is more secure than SHA256 (Read 1469 times)

This is not correct. All rounds of SHA256 have to be run sequentially. Calculating one sha256 hash it not a highly paralellizable task.
Granted, it requires far less RAM and CPU to calculate two SHA256 than one scrypt, but still your post is not accurate.

^This is spot on. From my understanding "security" the way OP is implying means the inability to 51% a coin. In this case, "security" is then defined by all of the hashpower working on the same blockchain not being held by a single entity. Thus, SHA coins currently have a HUGE advantage as ASICs begin to be rolled out. What makes for less GPU-mining makes for more security as more *distributed* has power comes online.

So 1KH/s of hashing power on a Scypt coin is more secure than 40,000 TH/s of hashing power on a SHA-256 based coin?  I mean your OP doesn't even make an attempt to include relative hashing power in your sweeping generalization that "Scrypt > SHA256".  

Also the idea that watered down Scrypt used by every altCoins to date uses "a lot of memory" is kinda silly.  The low security version of Scrypt (2^14, 8, 1) uses nearly 16MB of cache per thread, which is a lot given the cache capabilities of CPU & GPUs and the high security recommendation (2^20, 8, 1) requires a staggering 1GB of cache per thread.

You do know that the parameters (2^10, 1, 1) used in LTC (and thus every clone) are intentionally weakened and require only 128KB of RAM.  That can be optimized down to 64KB with some more complex design/coding.  The idea that Scrypt can't run parallel is well not true.  Your GPU right now runs Scrypt parallel and it doesn't use a single byte of your GPU main memory instead it uses the 64KB of register space per SIMD inside the GPU die.  The idea behind Scrypt is that it would optimally use the resources of a CPU and thus reduce the benefit of alternative designs (like GPU or FPGA or ASICs).  The scrypt paramters in altcoins so weaken the memory hard as to make CPU non-optimal.  A high end CPU has 6MB or more of high speed L1, L2, and L3 cache.  This allows Scrypt to operate very efficiently in CPU and avoid long and slow calls to main memory.  However lets look at the parameters used by LTC.  128KB per thread * 4 independent execution cores on average CPU = 512KB of cache required.  Except the CPU has 6MB (or more) of available cache.  More than 92% is idle, idle cache doesn't make alternative uncompetitive.  If fact it greatly increases the potential for improvement by making a design which better fits the requirements of the system.  This is why the author of Scrypt recommends the MINIMUM parameters for memory hardness (even in low security applications) be (10^14, 8, 1).

I'm sharing my idea to discuss about it. I'm not care about any specific coin in this topic, it is just a fact to discuss

What is the point of this post? Are you trying to just pump LTC now that people realize GOX was just empty promises?

In Scrypt algorithm design, has loops which uses a lot of memory. These loops should be done sequentially, therefore cannot be parallelelized.

In opposite, SHA256 parts can be runned parallel accross multiple core and uses a lot less memory.

In this regard, if someone wants to break Scrypt algorithm, he needs a lot more effort & resource. Altough SHA256 is secure enough these days with available computing powers (at least until release of quantum computers), based on the structure of these two algorithms and memory usage, i think Scrypt coins is a bit more secure than SHA256 coins.