

Bitcoin - implementation and protocol specs are a big problem - jeremie
https://gist.github.com/1005927

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

------
jeremie
These are not my thoughts, but found them interesting and worth sharing...

------
brevitae
Maybe instead of arguing about Bitcoin on blogs, we could argue about it on
GitHub with code. Seems more productive.

