Topic: How do we prevent Bitcoin forks (or should we)? - page 2. (Read 12687 times)

Yes.  The bitcoin paper describes how the network is compromised if over 50% of the nodes are not "honest."  That's inherent in the entire system.  Thus, incompatible or malicious forks are annoying and degrade the network, but shouldn't fundamentally compromise it until that 50% point is reached.  At which point, you have bigger problems.

The forks that are of more immediate concern are ones that destabilize or attempt to corrupt the network somehow, IMO.

Hopefully a good number of users will understand that using a "non-compatible with the current majority rules client" is going to result in a huge number of people making transactions that get delayed and generated coins disappearing which will damage the system's usefulness and the confidence of people in the system.

The particular scenario you mention is unlikely I think. In 3 years individuals who don't understand won't be minting hardly anything.

The "cryptographic race" for the longest chain to prevent double spending seems, as well as I can understand it, to be a pretty robust system against cheating and other similar maliciousness.

However, I am curious about how much of the rest of the system security relies on everyone "playing by the rules" and using the standard (or a minor variant thereof) bitcoin program. It seems to me that if someone convinced enough people to use an alternative bitcoin program that generated more or less valid blocks but potentially differed in some other way (perhaps a Trojan), he or she could break or undermine the whole system.

Here is one scenario to illustrate what I am thinking about:
Let's say that when the time comes for the value of generating a block to drop from 50 coins down to 25 coins, a big group of bitcoin users whine and decide that they don't want to generate fewer coins per block. So, they write a patch for the bitcoin program and make their own clients keep generating 50 coins per block. Now, the standard client will reject these 50 coin blocks as invalid, but if the "50 coiners" have a large enough group and accept both the 50 coin blocks and the 25 coin blocks, they could impose their will on the whole system. It seems to me the "25 coiners" would grind to a halt, rejecting block after block, and the "50 coiners" would happily build away a long chain of 50 and/or 25 coin blocks. I don't think the "50 coiners" would even need a majority of users to impose their will in this way. I suppose the "25 coiners" could stubbornly continue, and the project would fork into two different bitcoin systems, but this would be a major destabilization to the value of the bitcoins.

So, how do we prevent bitcoin from forking, down the road? At some point there is bound to be a large group of users unhappy with the status quo and an effort will be made to split the project, to the detriment of everyone. Can we build in a consensus about the valid identities of the client programs in the same way that we do for the transaction log (or is that already being done)? Or do people have the right to make a fork, despite the negative consequences?