[stygianguest]

Worse is better does not apply to bitcoin as a cryptographic system, only as a monetary system. As a cryptographic system it makes a clear choice for more features over simplicity.

Make no mistake, bitcoin is a very complicated system. Not for a piece of software, but for a cryptographic system. One that aims to replace the fundaments of our economic system. With such ambition, "it seems to work," is not good enough.

As someone who has spend some time hacking the bitcoin code, I have little confidence. Although I have not found any outright errors, the quality of the code shocked me. The code does nothing to provide structure and/or insight to the already complicated protocol. Basic protocol is mixed with parsing of messages and parallelism of the code. I for one, fully expect major and near fatal errors to be found in bitcoin.

[gwern]

> As someone who has spend some time hacking the bitcoin code, I would say I have little confidence.

There are a lot of differing opinions on this. I quoted Kaminsky at length as someone with major security credentials who is saying the opposite of you.

[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.

[stygianguest]

Sorry, missed that. Very interesting and indeed, his opinion easily trumps mine. However, I would like to see some evidence rather than the word of an expect (if only to learn). For example he says that "This code has the mark of having been audited by People Like Us", what marks would that be?

[tptacek]

I have no idea what he means by that.