Bitcoin - implementation and protocol specs are a big problem
gist.github.com
gist.github.com
-- 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.
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.
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.
---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.
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.