Isn't this why we need client diversity? Bad blocks will not be accepted by other clients, having 1/3 of client A, 1/3 of client B and 1/3 of client C will guarantee that no one client will fork the chain.
No, unless all three clients are precisely synchronized in every last detail to Satoshis code it guarantees spurious chain forks. The worst possible configuration is a 55/45 type split between two clients, but A/B/C is also not great - assuming the clients have subtle bugs. If none of the implementations are buggy, no problems.
I assume you mean that the C++ knowledge is needed in order to understand the current client, right?
Sure, but I mean you need to be aware of differences like uint32 vs int32 and so on.
For me it may be a more ideological standpoint that if the developers do not want to merge such a trivial change that will greatly enhance the community by the looks of the discussions - then they do not appear to want 3:rd party developers. The protocol is the heart of a P2P - can you blame people for wanting it somewhat fixed?
Real world protocols have uglyness that isn't worth fixing. My browser identifies itself as Mozilla, Gecko, Safari and Chrome simultaneously. It speaks HTTP/1.1 with extensions that never resulted in a version number bump and HTML "5" that has an ever shifting feature set.
Usually, there are more important problems to solve. I agree it'd have been better to have separate version numbers from the start, but it wasn't done.
That's FUD and bullshit. Seriously, a wrongly implemented client? "fork the blockchain"? "split the economy"?
You might want to read the code of conduct thread in the project development forum. Anyway, consider the worst case scenario. Two clients, A and B. A is Satoshis code and B is from somebody else. They have roughly equal usage.
During the implementation of B, by mistake the third condition in CheckBlock wasn't copied:
if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
Things work just fine for months, then one of two things happens. A miner whose clock is set wrong finds a block using client B and broadcasts it. Or, somebody notices the bug and decides to exploit it by deliberately mining a block with a far future timestamp.
Once this bad block is broadcast, the chain splits in two because client A refuses to accept it and the miners keep working on the existing block. But client B accepts it and begins building on top of it. The bogus chain B is now ahead of chain A ensuring the bad clients keep building on it.
This situation is pretty disastrous. Things will seem to work at first, because the same transactions will be accepted by both chains, but it has halved the network speed/security. Worse, double spending is now easily possible because the network can be turned against itself.
If you notice the split has happened, or were expecting it, you can broadcast a tx that sends the contents of your wallet to a new address you control. The tx has an nLockTime set to the current height of chain B and a low sequence number. It is immediately considered final and included by clients on chain B because their chain is one block ahead of chain A, but clients on chain A will wait a block before including it. After a block including your tx is broadcast on chain B, you broadcast a replacement tx changing the destination address to another new address you control. Clients on B ignore it because it's a double spend, but clients on chain A accept it because that tx wasn't finalized yet.
Congratulations, you just doubled your money - temporarily. You can now find merchants who are on chain B and spend your wealth with them to get whatever you want, safe in the knowledge that when the chains re-merge those spends will all be undone. Whilst you're doing this, the Bitcoin devs are running around like crazy trying to find/contact miners on chain B to get them to stop mining so A can overtake it. But, there's no central registration point for miners or even an announcements mailing list, so this will take a while. There will also need to be a crash upgrade of miners using client B to avoid the same bug being exploited over and over again.
Once the split occurs, there is less than 24 hours available to re-merge the chains before newly minted coins mature, become spendable and causing even more rolled back transactions.
Such an event would cause chaos and seriously undermine confidence in the whole Bitcoin system. Worse, if you have one such bug, it's a reasonable inference you weren't thorough enough, so attackers will immediately start looking for more.
This is why it's absolutely critical that re-implementations match the behavior of Satoshis code in every last detail, including features that aren't being used today. There are a lot of details in Bitcoin, so that's not easy to do, and the costs of failure could be very high if you client becomes popular.
