Special handlings in the bitcoin code?

[js2082]

I was browsing bitcoin source code, and I came across some special handlings:

    bool fEnforceBIP30 = (!pindex->phashBlock) || // Enforce on CreateNewBlock invocations which don't have a hash.
                          !((pindex->nHeight==91842 && pindex->GetBlockHash() == uint256("0x00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec")) ||
                           (pindex->nHeight==91880 && pindex->GetBlockHash() == uint256("0x00000000000743f190a18c5577a3c2d2a1f610ae9601ac046a38084ccb7cd721")));
    if (fEnforceBIP30) {
        for (unsigned int i=0; i<vtx.size(); i++) {
            uint256 hash = GetTxHash(i);
            if (view.HaveCoins(hash) && !view.GetCoins(hash).IsPruned())
                return state.DoS(100, error("ConnectBlock() : tried to overwrite transaction"));
        }
    }

    // BIP16 didn't become active until Apr 1 2012
    int64 nBIP16SwitchTime = 1333238400;
    bool fStrictPayToScriptHash = (pindex->nTime >= nBIP16SwitchTime);

    unsigned int flags = SCRIPT_VERIFY_NOCACHE |
                         (fStrictPayToScriptHash ? SCRIPT_VERIFY_P2SH : SCRIPT_VERIFY_NONE);

there are explanations in the code why this is done. But, isn't that in the future people (such as government) could release new versions with different behaviors? If more people using that client then the original bitcoin behaviors could easily be changed (e.g. add more coins, change coins per block, block release interval etc)? After all, the only thing in the network is the blockchain, as long as the new client is compatible with the existing blockchain, it doesn't matter if the future behavior is changed or not. Do I understand correctly?

[grue]

anyone can fork their own version, but good luck getting existing users to switch to your fork.

[cjp]

anyone can fork their own version, but good luck getting existing users to switch to your fork.

The person who makes the Satoshi client releases just seems to have that kind of power, especially when intimidation is added such as "you have to upgrade to 0.8 before may 15th". It's important to have some independent people look at the code of a release, so the community can be warned of any problems before the deadline.

I also stumbled on the piece of code mentioned here. This piece of code is clean: it is clearly necessary as part of the uncontroversial BIP 30. If you first read BIP 30 and then the code and comments, it becomes clear.

I'm having trouble understanding main.cpp. I think it's a huge mess, and potentially full of vulnerabilities. I've been following the development of the source code for some time, and readability is generally improving, but this piece definitely still needs lots of work.