[snip]
Even assuming that "the most difficult to recreate" implies total hashrate and not length thats fairly ambigous.
But anyway, piramida had it right. The comparator on line 80 (starting at line 76) is used by FindMostWorkChain, which in turn is called by ActivateBestChain. And there is no arguing with the code there.
The reason for the argumenting is fairly simple. If total cumulative hashing power is the deciding factor an attacking entity merely needs overwhelming hashing power to revert all transactions since any given point after the last checkpoint. In other words if any an event such as a sudden advance in technology, a majority if mining gear being sold after a reward halving etc ..., allows for a sudden shift in hashing distribution it is fairly easy to create a more difficult chain. To roll back time by time by n blocks within a timeframe with m further blocks you only need to beat the current chain (simplyfying here with a constant hashrate, principle stands one way or another though) (n+m)/m times the hash rate of the official network. E.g. a competing chain running at twice the hashing power of the official chain could roll back 1 day of transactions per passing day.
Using the length of the block chain, while being being having other disadvantages, is not susceptile to such a sudden increase in hashing power. To roll back n blocks within the next n blocks you need (again assuming the real chain stays at constant difficulty c) to exponentially grow the hashing power to catch up. Even assuming someone where to double the initial power c with every difficulty adjustment (and thus halving the time needed to create his own blocks) he would need 2^(2*no. of difficulty switches) the hasing power to catch up. In other words 4* the power to reverse 2016 blocks, spending the first week recreating the last 2016 blocks at double rate and spending the next week to create the 2016 new blocks at quadrouple rate. Trying to reverse 4032 blocks would require 16x current hashrate etc ...
While it is nice to argue about actual numbers I'm not sure what you are trying to get at here.
This type of consensus requires a majority so by definition the majority decides (eventually), regardless if they are the "attacker" or the "regular" chain.
As has been pointed out this actually also applies to the protocol software itself (let us consider abstract functionality and not a concrete implementation) and not just for the blockchain.
Unless you make very strong assumptions that are unrealistic and unwanted for the goals set out by bitcoin there is no circumventing the requirement for a majority of "correct" processes.
Of course one can always hypothetically "destroy" the protocol by assuming that the attacker owns a majority (and also maintains it, because probabilistic consensus means they have to infinitely often outnumber other participants or their "agreed upon" version can still change. This is one difference to deterministic consensus where the result does not just converge towards a probability of 1 but actually is 1).
As for the assumption of an ominous "kill switch". Effectively this is a majority attack on the (perceived) protocol functionality.
To me the only reasonable assumption where such a scenario could occur is if the ECDSA implementation of bitcoin was fundamentally flawed, allowing an attacker to spend from arbitrary addresses.
One could still try to migrate to another signing implementation but if there is no confidence in the validity of the current distribution of funds it makes little sense to try and salvage it as you cannot reasonably distinguish between rightfully owned addresses and those with stolen funds.
