Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
bitcoin - Theory looks solid, but implementation and protocol specs are a big problem.
I've spent some time reviewing the code and protocol that composes
bitcoin. My general feeling is that the crypto-theory is correct and
barring compromise of SHA-256 likely to be secure for the next 5 years
or so. The protocol and execution, however, are another matter. The
protocol is not well-defined and clearly designed by an amateur (that
is, not someone who has done much protocol implementation work). It's
a binary protocol with a smattering of length-prefixing, null
terminated strings, etc. The messages look reasonable, just a horrible
encoding. The rules of the protocol are poorly defined and tightly
coupled to implementation; the implementation is done by someone who
feels it's good and well to have only 5 major source files for 17
KLOC. Due to lack of a well-specified protocol, there is also a bit of
client monoculture going on.
It's worth noting that the whole system assumes SHA-256 -- the bitcoin
community says that rolling over to something else is just a matter of
introducing a new algo, but in actuality it's not nearly that simple.
The protocol has no concept of upgrading to different algos, so it
would necessitate a complete overhaul of the protocol (since there's a
lot of 32-byte fields in there) AND a re-computation/rollover of the
entire transaction history. I think there might be a way around the
latter problem if the protocol introduce the idea of transaction
pruning, but again it's a big protocol change and you need a majority
of the network to agree to it.
Having the ability to upgrade algos is really, really important IMO.
As it stands, the entire bitcoin economy would go to zero, nearly
instantaneously, if SHA-256 is broken. There MUST be a way for the
network stay ahead of crypto changes and improve security over time.
Rotation of currency, as in the real world, must be designed in.
The protocol also has had no thought put into it re: network
architecture -- there are peers and that's it. Due to the
cryptographic nature of transactions, it's simply not possible to have
realtime transactions with bitcoin as the network scales (it already
take 5-10 mins on average for the network to see a single
transaction). Thus, there will need to be some concept of a node in
the network that can facilitate interactions between two peers in a
faster fashion, with the assumption of a measure of trust. You
shouldn't REQUIRE it, of course, but it should be defined I think.
There's also probably the need for some concept of a super-peer (or
some such) that enable the system to not require absolutely every peer
to see every transaction. I.e. there needs to be some ability to have
a gradient of trust in the network; you don't have to trust anyone,
but as with real life it makes certain types of things easier.
I can't speak to the economic implications of limiting # of bitcoins
to only 21 million -- it's probably based on the fixed rate of coin
generation and the desire to have it stop by 2016. It feels a bit
arbitrary though. If it were me, I'd have a larger max (signed 32-bit
integer, anyone?), and allow the generation to happen over longer
period of time; I suspect this would reduce the crazy rate of
appreciation in value, making a transition process more stable and
less prone to the big dips sure to happen with bitcoin due to
speculators. Also, if you are serious about making a currency for the
whole internet, 21 million seems like a few order of magnitude too
small due to number of participants.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment