Let me preface this with, I'm not exactly sure how bitcoind deals with receiving two equivalent blocks (two different block 213s for example). Obviously, once it receives a block 214 it'll keep the 213 referenced by its 214. But until then, from my research (which may be incomplete, but I can't find much about this) it seems that it keeps the block it received first. This, however, is a breach of the bitcoin protocol.
I doubt that
The bitcoin protocol specifies that in the case of a blockchain fork the winning chain is the one with the most work in it.
The longest chain, which can not be judge when you have 2 chains of equal length.
Clearly, the first block received is not necessarily the one with the most work - the block with the most work would be the block with the lowest hash.
No. Finding a hash is not deterministic. You could find a lower hash value in the same time as you would find a higher hash value. It could even take you 100 times as long to find the higher (acceptable) hash. This would also open a way for miners to "cheat".
Lets say miner A finds a block B
A with very low hash (by just beeing lucky), but decides not to publish it yet. Its relativly safe for A to do this. If now miner B finds another block B
B with a hash higher than B
A miner A can publish B
A withheld until now. Thus block B
B is useless and miner A had more time to find a follow up block for B
AFor all neutral miners (miners who didn't mine either version block 213) and non-mining nodes, replacing a block is a normal occurrence that doesn't cost anything. Therefore, following the protocol and replacing the accepted block by the block with the lowest hash seems like an intuitive thing to do. It is also a useful thing to do - it immediately ends the current situation where it is more profitable to mine blocks with less transactions, unless the transactions pay a much higher fee than otherwise would not be necessary.
Wut? Why? Lets just assume the problem above is of no matter, what does a low hash value has to do with the amount of transactions a block contains?
I see no reason why bitcoin core does not follow one of the most basic rules of the protocol, especially when not following it has a cost in network utility.
Yes, I do know that Gavin's O(1) block propagation time solves the problem too, however these solutions can coexist. And implementing replace-by-lowest-hash would be extremely simple, compared to the O(1) propagation time solution.
Again, replace-by-lowest-hash would give some miners an advantage if they withhold a newfound block and publish it later.