diff --git a/gistfile1.txt b/gistfile1.txt
 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.
	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.