[tptacek]

You are citing as an authority on code quality someone who says Bitcoin should use Bcrypt instead of SHA-256 because Bcrypt is less amenable to hardware optimization.

I hope to make the starburst of applicable points that follow from this by implication instead of explicit argument.

[gwern]

I'm afraid you're going to have to be explicit, because the idea of using Bcrypt for that reason makes perfect sense to me - the logic that makes Bcrypt better than SHA-256 for passwords seems to apply nicely to Bitcoin. Hardware optimization privileges the few who can invest in the hardware over the many who are able to run more commodity hardware, and is exactly contrary to the P2P Bitcoin ethos.

(A similar point applies to time-lock puzzles: http://www.gwern.net/Self-decrypting%20files Why were Rivest/Shamir/Wagner unhappy with brute-force decrypting? Because it's so amenable to hardware optimization. Why were subsequent researchers unhappy with successive squaring and looked for memory-bound hashes? Because squaring is still implementable in hardware.)

[asdfaoeu]

Bcrypt isn't specifically harder to compute on GPUs. It just has an adjustable amount of work it has to do which increases the load. Bitcoin effectively has the same thing with the difficulty.

[gwern]

...Not really. The point is not that you can make it harder, as you say both Bcrypt and zero-finding in SHA hashes can be adjusted and made harder. The point is that the constant factor speedups available from specialty hardware are greater for SHA than they are for Bcrypt.

[tptacek]

First, I don't think your specific point is true. Second, and more importantly, the benefit of hardware isn't that it changes the constant factors; it's that it parallelizes the search. The whole point of scrypt is to create a state explosion that prevents that parallelization.

[gwern]

Parallelization is a constant factor. If you have 1000 processors, you get a constant-factor one-time speedup of 1000x (or less). No complexity class changes.