Is Bitcoin that really decentralized, as you believe?

[RHorning]

I happen to agree with at least the basic premise of this thread, that there still is some central authority related to the development of this concept of Bitcoins.  What Satochi did was to write up essentially a "constitution" in the form of a network protocol in a reference implementation of Bitcoins.  This is useful, but there is a need to add to this with two very important things:

• Protocol Documentation - The specification of the Bitcoins protocol really needs to be nailed down and defined in a formal manner, equivalent to an RFC or an ISO specification document.  BTW, this is something I'm actively working on right now so I'm not merely trying to cry about this particular issue, although I'd like to get some help along these lines or at least some pointers on what parts in the current code base would be better to look at in terms of pulling out the network protocol in a formal sense.  I'll get it down eventually, but "many hands make light work" on a project of that magnitude.
• Alternative Implementations - For a robust network to really take root, many different implementations of the networking protocol need to be made above and beyond the reference implementation.  Preferably, no particular implementation should have more than 50% of the network in terms of keeping the concept decentralized and to be robust in terms of keeping it from getting "hijacked" by government control or other problems of a single person or a small group thwarting the network as a whole.

Mind you, the reference implementation is always going to be needed, and I don't want to dismiss Satochi's contributions to the project in any way at all.  I haven't seen nearly the resistance to getting these kind of tasks getting accomplished compared to other peer to peer networks that I've been involved with, but it is something that should be discussed.  Of these, simply documenting the protocol is IMHO even more important in the short term.

[throughput]

...
This is useful, but there is a need to add to this with two very important things:

• Protocol Documentation - ...
• Alternative Implementations - ...

I have to add to this list of the very important things a set of software tests, that will validate any implementation
and tell us, whether or not it comply with the protocol specification and with the rules currently active and whether it is "honest" or not, etc.
That set of tests together with a complete protocol specification should produce sooner or later
some alternative implementations.
A lot of alternative implementations, and they will be as good at interoperating with the others, as good
are the tests and the specification.

However, I still doubt, that such alternative implementations will be functional, interoperable and secure and still will be independent of
any central authority. 
Somebody still have to decide on specification and tests. It just cannot self-organize out of thin air.
Do you get my point? You have to have some Working Group/Consortium/Standards Committee/Development Center/Whatever you name it to be recognized as an authoritative source of decisions on specifications and validity tests for BitCoin implementations.
It is obvious, that it is required for future interoperability, but still nobody recognizes himself as such an authority.

[throughput]

... a set of software tests, that will validate any implementation
and tell us, whether or not it comply with the protocol specification and with the rules currently active and whether it is "honest" or not

It doesn't work that way. A test suite can tell you whether or not an implementation passes the test suite. It can't tell you whether or not the implementation is "valid" or "honest" or "compliant".

For example, a dishonest implementation might work properly except between 01:13:53 and 01:13:54 each morning. Or, it might work properly whenever it's running on an IP address that's not from Nigeria.

Open-sourcing the code is one way to strengthen confidence in the honesty of the code.

Ofcourse!
I'm happy you understand that!

A careful set of tests boosts the speed of development process, making it test-driven.

Open-sourcing the code, that is thoroughly and automatically tested, is the best way to strenghten confidence in the correctness of the code.
By "honest" I meant what is meant in the whitepaper, particularly, whether or not it accepts or produces incorrect transactions.
Ofcourse tests are of no use, if we testing a black box, which is simulating a honest Bitcoin node.
We can only test how well does it simulate the honest node.
I'm happy, that everyone here understand that.

[RHorning]

... a set of software tests, that will validate any implementation
and tell us, whether or not it comply with the protocol specification and with the rules currently active and whether it is "honest" or not

It doesn't work that way. A test suite can tell you whether or not an implementation passes the test suite. It can't tell you whether or not the implementation is "valid" or "honest" or "compliant".

But of course a good open source test suite can be added to and strengthened over time, giving the advantages of both a test suite and an open source implementation.  Frankly, I think this is a good thing to implement too, and I like the idea.  The point being that there are things which can be done to strengthen Bitcoins  Sure, a verification is only as good as its test, but tests can be useful for independent confirmation that a particular implementation may be compliant to a specification.

The operable word here is "may", as most of computer science doesn't deal with a mathematically tight proof of conformance.  Most of the time computer software development doesn't have the time or the resources (read manpower) to perform such a rigorous proof.  Even the programming gold standard for bug-free development, the software for the Space Shuttle guidance computers, doesn't ever really go that far.  No sane software development company could ever devote the resources to perform that kind of test and no sane individual would ever spend that kind of effort even with an open source software application except for only the most critical kernel parts of an operating system.

[Red]

I want to point out that I have heard of several existing "alternative implementations" all created by people other than Satoshi.

People have replace the SHA-256 algorithm with a faster one. Made it work on many different operating systems and hardware configurations. Each of these is a separate and equal alternative implementation.

When you create an alternative implementation that doesn't mean you have to start from scratch or understand the details. You could let a C++ to Java or C# translator do most of the work, while you remain oblivious. Others could pick up your work, learn specific parts, make modifications and remain oblivious to the rest of the system.

Now, I'm not against protocol specifications written in an abstract language. Nor am I against regression testing. However, neither is required for BitCoin to become successful.

[RHorning]

However, I still doubt, that such alternative implementations will be functional, interoperable and secure and still will be independent of
any central authority. 
Somebody still have to decide on specification and tests. It just cannot self-organize out of thin air.
Do you get my point? You have to have some Working Group/Consortium/Standards Committee/Development Center/Whatever you name it to be recognized as an authoritative source of decisions on specifications and validity tests for BitCoin implementations.
It is obvious, that it is required for future interoperability, but still nobody recognizes himself as such an authority.

The advantage of focusing on the protocol rather than the implementation is that changes in a protocol specification are easier to spot, to review, and to vet.  In addition, if an "upgrade" in a specification introduces a harmful behavior, the various implementations will announce such a problem very quickly and there may be many or most implementors who refuse to go along with the changes in the implementation.

By relying upon "documentation in the implementation", it provides fewer speed bumps on the road to subversion of the network and provides more vectors for a central authoritarian organization of some sort to make changes without consensus from a much larger group of concerned individuals.  That is my point.  It isn't a perfect solution, but it is a solution that can help to strengthen the de-centralization of the project and put the network into the hands of the users.

[Quantumplation]

...
This is useful, but there is a need to add to this with two very important things:

• Protocol Documentation - ...
• Alternative Implementations - ...

I have to add to this list of the very important things a set of software tests, that will validate any implementation
and tell us, whether or not it comply with the protocol specification and with the rules currently active and whether it is "honest" or not, etc.
That set of tests together with a complete protocol specification should produce sooner or later
some alternative implementations.
A lot of alternative implementations, and they will be as good at interoperating with the others, as good
are the tests and the specification.

However, I still doubt, that such alternative implementations will be functional, interoperable and secure and still will be independent of
any central authority. 
Somebody still have to decide on specification and tests. It just cannot self-organize out of thin air.
Do you get my point? You have to have some Working Group/Consortium/Standards Committee/Development Center/Whatever you name it to be recognized as an authoritative source of decisions on specifications and validity tests for BitCoin implementations.
It is obvious, that it is required for future interoperability, but still nobody recognizes himself as such an authority.

So who develops the tests?  Wouldn't they become some central authority?

[Red]

So who develops the tests?  Wouldn't they become some central authority?

FTW!

[RHorning]

So who develops the tests?  Wouldn't they become some central authority?

No.  Especially if it becomes a suite of tests instead of simply a single test, and merely having various algorithms posted from concerned individuals that want to get involved.  The posting forum may be a "central authority", but not the tests themselves.

I hate to point out the obvious, but by posting here you are implicitly endorsing the central authority of this forum too.

[Quantumplation]

The "They" in that sentence was those who wrote the tests.

The fact of the matter is, by throughput's reasoning, there will ALWAYS be a central authority, because he's twisting and bending the term "decentralized" to unreasonable extents.  Eventually, you reach the point of "Well, I'm trading with someone else, aren't they the central authority of my transaction?  Aren't I the central authority of my own funds?  Isn't the people who exchange bitcoins for USD a central authority?"

[throughput]

The fact of the matter is, by throughput's reasoning, there will ALWAYS be a central authority, because he's twisting and bending the term "decentralized" to unreasonable extents.  Eventually, you reach the point of "Well, I'm trading with someone else, aren't they the central authority of my transaction?  Aren't I the central authority of my own funds?  Isn't the people who exchange bitcoins for USD a central authority?"

Sorry, no, you completely misunderstood my topic.
I'm trying to point out, that instead of just screening themself from hard security problems, that come from the fact of
them being a central authority, developer community would better analyse the threats and protect the project from them.
Right now, whitepaper says, that there is NO such authority, so you may conclude, that the project is totally free from such threats.
1. That is not true. It is obvious to everyone here, I hope.
2. I'd like to read in whitepaper, why those threats are low risk. For me that are threats to my money.
3. I'd like to see the list of known threats with their risk rating and their consequences OPEN and well discussed,
not just brave wording about invulnerabilities of the BitCoin compared to others.

PS: Having a paranoia does not release you from under surveillance, I hope you got the joke.

[Anonymous]

The fact of the matter is, by throughput's reasoning, there will ALWAYS be a central authority, because he's twisting and bending the term "decentralized" to unreasonable extents.  Eventually, you reach the point of "Well, I'm trading with someone else, aren't they the central authority of my transaction?  Aren't I the central authority of my own funds?  Isn't the people who exchange bitcoins for USD a central authority?"

Sorry, no, you completely misunderstood my topic.
I'm trying to point out, that instead of just screening themself from hard security problems, that come from the fact of
them being a central authority, developer community would better analyse the threats and protect the project from them.
Right now, whitepaper says, that there is NO such authority, so you may conclude, that the project is totally free from such threats.
1. That is not true. It is obvious to everyone here, I hope.
2. I'd like to read in whitepaper, why those threats are low risk. For me that are threats to my money.
3. I'd like to see the list of known threats with their risk rating and their consequences OPEN and well discussed,
not just brave wording about invulnerabilities of the BitCoin compared to others.

PS: Having a paranoia does not release you from under surveillance, I hope you got the joke.

There is something you may have missed.The developers will not be the first "targets" it will be the merchants who accept bitcoins that will be the canaries in the mine,so to speak.An attack will follow the money first rather than going for the harder targets.As a merchant I wouldnt be taking the risk if I didnt believe that the project was as vulnerable as you claim.The biggest risk is lack of confidence ,which you appear to be trying your best to bring about.This is an issue I have with people such as Alex Jones who push fear and have no answers to the problem.There are enough things to worry about in everyday life without postulating on things you cannot control.Your fears are similar to worrying about some overarching world government when the local gang poses the most danger to your life.You should go away and think about the constructive efforts you can take rather than indulge in destructive thinking.

[Quantumplation]

The fact of the matter is, by throughput's reasoning, there will ALWAYS be a central authority, because he's twisting and bending the term "decentralized" to unreasonable extents.  Eventually, you reach the point of "Well, I'm trading with someone else, aren't they the central authority of my transaction?  Aren't I the central authority of my own funds?  Isn't the people who exchange bitcoins for USD a central authority?"

Sorry, no, you completely misunderstood my topic.
I'm trying to point out, that instead of just screening themself from hard security problems, that come from the fact of
them being a central authority, developer community would better analyse the threats and protect the project from them.
Right now, whitepaper says, that there is NO such authority, so you may conclude, that the project is totally free from such threats.
1. That is not true. It is obvious to everyone here, I hope.
2. I'd like to read in whitepaper, why those threats are low risk. For me that are threats to my money.
3. I'd like to see the list of known threats with their risk rating and their consequences OPEN and well discussed,
not just brave wording about invulnerabilities of the BitCoin compared to others.

PS: Having a paranoia does not release you from under surveillance, I hope you got the joke.

The whitepaper refers to no central authority in the system.  The algorithm and protocol set forth by the whitepaper DO have no central authority, as anyone can write a client for the bitcoin network.  The fact that there's only one community of developers right now is not a flaw in bitcoin which makes it "only partially decentralized", but a flaw in the breadth and scope of it's current community.

For example, let's suppose some common technology or product hadn't been invented yet, say, telephones.  If they were invented tomorrow, and someone started selling them, there would be only one company producing and selling them.  By your arguments put forward, you would classify this as a monopoly.  While in the strictest sense of the word it is, when taken in context it is not, because there's been no CHANCE for competition to be established.  Soon, more companies will start selling phones, and more people will start buying them.  Some providers might change the underlying technology of the phone to, for example, be encrypted, or transmit data wirelessly.  They're still phones, but the original company has no more "centralized control" over them than satoshi will have over bitcoin, should it take root.

If you want to see a list of known threats and their risks, read the forums.  There's plenty of discussion about 50% attacks, cracking the hashing problem, the factoring problem, DDOS attacks, etc.

[Anonymous]

The fact of the matter is, by throughput's reasoning, there will ALWAYS be a central authority, because he's twisting and bending the term "decentralized" to unreasonable extents.  Eventually, you reach the point of "Well, I'm trading with someone else, aren't they the central authority of my transaction?  Aren't I the central authority of my own funds?  Isn't the people who exchange bitcoins for USD a central authority?"

Sorry, no, you completely misunderstood my topic.
I'm trying to point out, that instead of just screening themself from hard security problems, that come from the fact of
them being a central authority, developer community would better analyse the threats and protect the project from them.
Right now, whitepaper says, that there is NO such authority, so you may conclude, that the project is totally free from such threats.
1. That is not true. It is obvious to everyone here, I hope.
2. I'd like to read in whitepaper, why those threats are low risk. For me that are threats to my money.
3. I'd like to see the list of known threats with their risk rating and their consequences OPEN and well discussed,
not just brave wording about invulnerabilities of the BitCoin compared to others.

PS: Having a paranoia does not release you from under surveillance, I hope you got the joke.

The whitepaper refers to no central authority in the system.  The algorithm and protocol set forth by the whitepaper DO have no central authority, as anyone can write a client for the bitcoin network.  The fact that there's only one community of developers right now is not a flaw in bitcoin which makes it "only partially decentralized", but a flaw in the breadth and scope of it's current community.

For example, let's suppose some common technology or product hadn't been invented yet, say, telephones.  If they were invented tomorrow, and someone started selling them, there would be only one company producing and selling them.  By your arguments put forward, you would classify this as a monopoly.  While in the strictest sense of the word it is, when taken in context it is not, because there's been no CHANCE for competition to be established.  Soon, more companies will start selling phones, and more people will start buying them.  Some providers might change the underlying technology of the phone to, for example, be encrypted, or transmit data wirelessly.  They're still phones, but the original company has no more "centralized control" over them than satoshi will have over bitcoin, should it take root.

If you want to see a list of known threats and their risks, read the forums.  There's plenty of discussion about 50% attacks, cracking the hashing problem, the factoring problem, DDOS attacks, etc.

In marketing terms bitcoin has the "first mover advantage" . This is not a sinister central monopoly it is an age old advantage for the entrepeneur to spot a market need before anyone else does.In the days before government granted monopolies through patents and copyrights it was how merchants could establish brand recogniton and beat other competing companies with exactly the same products.First to market is an extremely important thing in a system where government monopoly is impossible.The solution is to find a niche that no one else has recognised and establish trust with your customers.An example is google as the default search engine in most browsers.How many people never change their default search engine even though something else might be better?Its because google was the first to do what they do best and people had a need for it.Once you fulfill  a need as a merchant customers are extremely loyal.

[Quantumplation]

An example is google as the default search engine in most browsers.How many people never change their default search engine even though something else might be better?Its because google was the first to do what they do best and people had a need for it.Once you fulfill  a need as a merchant customers are extremely loyal.

Poor example, because there IS nothing better.

[Olipro]

Your person makes no difference to me. Only your words live here.

And your words either point out what is obvious to even the most casual observer.
1) Everyone is not a developer.
2) The code makes the rules.
3) Therefore, developers of the code make the rules.

No shit Sherlock! That really does go *without* saying.

Oh God! They understand me!
Yes!
But that is not just an obvious property, but is also something, that have a security implications.
And I thought, that it should get duscussed from a security point of view.
At least, that doing so will somehow contribute to security and robustness of a payment system.
1) The rules are buried deeply into the binary.
2) The authority, that guarantees the tamperproof transactions is the rules that runs on the majority of the nodes.
3) The majority of users will download the binaries, not compile them.
4) Right now, there is only one distribution channel for binaries, the sourceforge.
5) No, binaries are not cryptographically signed.
...
PROFIT?

You [only] need a keylogger on the computer, that uploads binaries to sourceforge, to fully control the rules.
Does anybody run NOW intentionally dishonest nodes to inject dishonest transactions to check that they are really and continuously rejected by the majority?
If not, nobody will notice, that rules became weaker in the subverted binaries.
So, the only person, who knows that secret will remain the attacker, who subverted them.

...waffle waffle waffle...

There is no way to steal the existing bitcoin value by anyone, developer or not.

1. Who said that?
2. Does others agree on that?
3. Can that be proven?
4. Is that proven?

Why not steal bitcoins with transactions,

...waffle waffle waffle...

If there is, you certainly haven't pointed anything out.

In the case where you do say something that is not obvious to everyone, it is generally either misguided or nonsensical.

Sorry, that is me.

I'm wondering, why does anyone not discuss obvious security features of the system?
I am trying to invent attacks (sometimes stupid attacks), but nobody says, that everything
is already protected, because somebody worried before me.
They just say it is because of my drugs.
And my drugs aren't really appreciated here.

I think I went over this before but I'll do it again, albeit in harsher terms this time:

just because you are too stupid to evaluate the system in both source code and binary form does not mean that everyone else is

Which means that in order for your ridiculous ideas to bear fruition it would require that EVERYONE capable of understanding the code and binaries be part of a HUGE CONSPIRACY in order to successfully defraud everyone who is unable to understand it.

Let me give you an extremely simple real-world example that will utterly destroy your paranoid rants.

The Linux Kernel

Need I say any more?

[Quantumplation]

Your person makes no difference to me. Only your words live here.

And your words either point out what is obvious to even the most casual observer.
1) Everyone is not a developer.
2) The code makes the rules.
3) Therefore, developers of the code make the rules.

No shit Sherlock! That really does go *without* saying.

Oh God! They understand me!
Yes!
But that is not just an obvious property, but is also something, that have a security implications.
And I thought, that it should get duscussed from a security point of view.
At least, that doing so will somehow contribute to security and robustness of a payment system.
1) The rules are buried deeply into the binary.
2) The authority, that guarantees the tamperproof transactions is the rules that runs on the majority of the nodes.
3) The majority of users will download the binaries, not compile them.
4) Right now, there is only one distribution channel for binaries, the sourceforge.
5) No, binaries are not cryptographically signed.
...
PROFIT?

You [only] need a keylogger on the computer, that uploads binaries to sourceforge, to fully control the rules.
Does anybody run NOW intentionally dishonest nodes to inject dishonest transactions to check that they are really and continuously rejected by the majority?
If not, nobody will notice, that rules became weaker in the subverted binaries.
So, the only person, who knows that secret will remain the attacker, who subverted them.

...waffle waffle waffle...

There is no way to steal the existing bitcoin value by anyone, developer or not.

1. Who said that?
2. Does others agree on that?
3. Can that be proven?
4. Is that proven?

Why not steal bitcoins with transactions,

...waffle waffle waffle...

If there is, you certainly haven't pointed anything out.

In the case where you do say something that is not obvious to everyone, it is generally either misguided or nonsensical.

Sorry, that is me.

I'm wondering, why does anyone not discuss obvious security features of the system?
I am trying to invent attacks (sometimes stupid attacks), but nobody says, that everything
is already protected, because somebody worried before me.
They just say it is because of my drugs.
And my drugs aren't really appreciated here.

I think I went over this before but I'll do it again, albeit in harsher terms this time:

just because you are too stupid to evaluate the system in both source code and binary form does not mean that everyone else is

Which means that in order for your ridiculous ideas to bear fruition it would require that EVERYONE capable of understanding the code and binaries be part of a HUGE CONSPIRACY in order to successfully defraud everyone who is unable to understand it.

Let me give you an extremely simple real-world example that will utterly destroy your paranoid rants.

The Linux Kernel

Need I say any more?

Fucking win.

[Red]

I didn't notice this earlier or I would have responded.

But that is not just an obvious property, but is also something, that have a security implications.

Who wrote the code doesn't have security implications. What the code does, has security implications. If you don't believe the binaries match the source, then build the source yourself. If you can't ask for a binary from someone you trust that has. If you can't do either. You are what we call SOL.

1) The rules are buried deeply into the binary.
2) The authority, that guarantees the tamperproof transactions is the rules that runs on the majority of the nodes.
3) The majority of users will download the binaries, not compile them.
4) Right now, there is only one distribution channel for binaries, the sourceforge.
5) No, binaries are not cryptographically signed.
...
PROFIT?

This makes no sense to me. See above.

You [only] need a keylogger on the computer, that uploads binaries to sourceforge, to fully control the rules.
Does anybody run NOW intentionally dishonest nodes to inject dishonest transactions to check that they are really and continuously rejected by the majority?
If not, nobody will notice, that rules became weaker in the subverted binaries.
So, the only person, who knows that secret will remain the attacker, who subverted them.
He will only need to wait, until his version dominates the network.
He will steal all your transactions with another version of a client,
since binaries, that are running by the majority, were specifically set up to allow dishonest transactions,
but not to make them.

Perhaps, that could become disclosed and fixed later, but that will hit the reputation of the system very much.
Perhaps not.
Why don't you tell what you think of that?

This almost makes sense, but not really. Most of your points are off enough to be dismissed out of hand. However, I thought of a better example that others might grasp so I'll mention it in a follow up post.

1. Who said that?
2. Does others agree on that?
3. Can that be proven?
4. Is that proven?

1. I did.
2. Yes, others agree. Just ask.
3. Implemented correctly, yes it can be proven and the risks of the system documented based upon the strength of the crypto. If there are bugs in the code, it is open for anyone to point them out and/or fix them. I tried. I failed. Others may try as they think weakness.
4. Yes, he did a great job in the white paper.

Why not steal bitcoins with transactions, that are dishonestly injected into the blocks, honestly solved by the subverted binaries?
Who will prevent that from going, if the majority is specifically subverted to accept such transactions?
Well, that still may become disclosed. Or not? If it will, how and after which amount of time/bitcoins?
Why not send every transaction to a different Bitcoin address,
just ask it every time from a web-site, or just from DNS?
Or just to a randomly generated address, to destroy the value?

You can't put inconsistent transactions into blocks. The other nodes will reject your blocks.
The entire transaction log is public. Even if you were able to subvert most of the nodes, if you expect the other nodes to accept your transactions they have to be consistent valid transactions.

If you can subvert all the nodes, then by definition you are not running a bitcoin network. You are running a "your silly coin" network.

The rest is nonsense.

After all, why only I do the analysis?
Do you care?
Or, is that already discussed and known to everyone and obvious for all, except me?
Then, please, tell me. It is not obvious. Really not!

Everyone analysis. Just ask Knightmb. Do you think he would have spend one nickel on server time if stealing coins was easier?

You are foolish, to not presume that the community has not already considered every point that pops off the top of your head.

I'm wondering, why does anyone not discuss obvious security features of the system?
I am trying to invent attacks (sometimes stupid attacks), but nobody says, that everything
is already protected, because somebody worried before me.
They just say it is because of my drugs.
And my drugs aren't really appreciated here.

Everyone tries. Everyone fails. Everyone tries again.

You should try again. Just try to understand the system first. Then hack it.

[Red]

As close as I figure everything throughput is babbling about, comes down to a single use case.

1. Superhacker "Red" wants to steal bitcoins without anyone finding out.
2. Red downloads the bitcoin source from sourceforge.
3. Red adds a little extra bit of hidden code that covertly uploads the node owner's wallet (private keys) to Red's super secret hacker server.
4. Red uploads the hacked binary to sourceforge or somewhere else that people will think it is an official version.
5. People trust the hacked version and begin to use it.
6. As the wallet files come in, Red uses their public keys to submit valid transactions sending the coins to untraceable super secret bitcoin addresses.

He suggests this scenario could be avoided by signing the binaries with a trusted public key/certificate.

[Olipro]

no, because Throughput will just say that someone will hack the person in possession of the key and compromise it.