I'll repeat.
1. There is two separate entities, both sharing the same name NOW, which is not required at all:
a) Bitcoin payment system as idea, mathematic model, protocol standard, rules
b) Bitcoin software project, the implementation of the idea, the model, the protocols, etc,
the binaries.
2. Payment system have it's own set of (possible) weaknesses and vulnerabilities,
only some of them are caused by the software implementation, that is NOW available
for public download from sourceforge. Diversity of implementations helps
in isolating the software vulnerabilities in smaller subset of nodes, which does not
necessarily form a majority.
3. The Bitcoin payment system heavily depends on
the majority of the nodes to be "fair"
and play by the rules. This is by design, not an implementation specifics. Somehow we just
hope, that majority will just be fair. There is not any protection from nor detection of the otherwise case.
4. To control the payment system an adversary only need to control the majority of the nodes,
whatever reason he want to control the payment system for, we do not limit his motives for
the purposes of our analysis and never try to define them, dear Red. He may aswell just
wish to hit a competing payment system, never try to steal your coins. The less users
accept bitcoins, the less they are worth, do you understand the idea? Reputation is everything.
However nothing restricts him in his deeds.
Question to all: What exact threats to the payment system arise in the event of an adversary
temporarily controlled the majority of nodes for a long enough amount of time? Perhaps going
undetected. I count that threats as real world threats, not only imaginary, so request
them be documented, at least here.
5. In the situation, where there are several equally popular implementations and no
implementation run on the majority and at every moment every user may decide to
switch to another implementation, then the payment system becomes less affected by
the vulnerabilities of a single implementation and the vulnerabilities of implementation's
software management process.
6. Even when there is only single implementation, diversifying the binary distribution, as with
GNU/Linux, makes it much harder to subvert only one binary
and write on the forum something like:
News: *** ALERT *** Please upgrade to 0.9.10 ASAP for an important bugfix! Do not accept Bitcoin transactions as payment until you upgrade!
to force the majority to upgrade to subverted binary and become controlled.
7. Signing binaries, publishing signatures, diversifying the binary distribution channels
makes it harder to subvert just one single binary for subverting the whole network.
Just adding a Bittorrent channel improves on that, but does not solves the problem
completely.
As usual, system security is as strong, as it's weakest link's.
And I found, that the current process of distributing the binaries for Bitcoin payment system makes that payment
system too
risky to convert real quantities of real money into bitcoins.
There is only one "official" site distributing binary. That makes the entire Bitcoin
payment system as secure as desktop of the user who have write-access to sourceforge.
I hope he trusts his desktop and network. But why should I? Even if I distrust his computer
and compile by myself, that does not protect the majority, which I believe, just downloads
the binary.
What is your opinion?
Would you object against my perceived value of the risk or against the vulnerability as a matter of principle?
Meantime, haven't I found too much central points from which Bitcoin can be controlled for it to become enough centralized?
I always thought, that one central point is already enough for that... But, well, okay, that is your forum, your rules.