[Amincd]

These parts suggest the author doesn't understand it that well:

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

Bitcoins are generated until 2140.

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

Each coin is made up of 100,000,000 atomic units, so using the bitcoin denomination is arbitrary, and smaller denominations can be used as the value of a bitcoin increases.

[antiscam]

Those are the most superficial points of the post; everything else he says is spot on, particularly the disconnect between the claim the the protocol is easy to update and the nearly impassable practical obstacles to doing so for a contentious update.

[Amincd]

He's studying the protocol yet doesn't know when generation ends or that each coin can be divided down to the eight decimal place. It doesn't give me confidence he has done a thorough job.

The author also writes:

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

When transactions were never meant to be real-time.

The only criticism that is valid IMO is this:

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

But he offers no means of doing this while maintaining a decentralized network.

[antiscam]

I think you've misunderstood his focus. He's describing the network protocol, not the overall "Bitcoin system" that's sometimes called the "Bitcoin protocol." He explicitly points out that the economic details are beyond the scope of his argument.

You could tie an upgrade of the protocol to a consensus by a majority (or perhaps supermajority, if you're clever) of mining strength. Or you could try to give up the total decentralization of Bitcoin, given that it's an illusion anyway and the source of most of the expense, security problems, and unwieldiness that will come to haunt the protocol.

[Amincd]

That's a good point, but if he studied the protocol, he should still know when bitcoins stop being generated and how divisible they are.

---You could tie an upgrade of the protocol to a consensus by a majority (or perhaps supermajority, if you're clever) of mining strength.---

The problem then would be that a >50% attack could overtake the entire network by inserting malicious code in the upgrade.

As it is now, the damage that a >50% attack could do is somewhat limited as long as it doesn't persist for too long.

---Or you could try to give up the total decentralization of Bitcoin, given that it's an illusion anyway and the source of most of the expense, security problems, and unwieldiness that will come to haunt the protocol.---

Decentralization is the only way a program that would be as targeted by law enforcement as bitcoin can survive.

[antiscam]

Bitcoin's not at all resilient in the face of an attack by a government.

You're right about limiting damage from a 50% attack, however. Of course, you could agree in advance on an amount of time the majority of hashing power would have to assert that an upgrade was needed, but it's possible that would raise other problems. It may be that there's no good way to handle upgrades without an out-of-band mechanism, but if so, that counts as a strike against Bitcoin, not one in its favor.