Bitcoin Core Replace By Lowest Hash

[CJYP]

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.

The bitcoin protocol specifies that in the case of a blockchain fork the winning chain is the one with the most work in it. 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. For 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. 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.

EDIT:
To avoid bumping this, I'm just going to edit this post.
I disagree with some of Shorena's specifics, but I can't refute the general point which is that it would open up some possibilities for attack that currently aren't possible.

[shorena]

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_A

For 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.

[gmaxwell]

the block with the most work would be the block with the lowest hash

Incorrect. The block with the best target (and target history sum, more specifically) is the one with the most work. Having a lower hash is just chance.

The protocol is that the first valid chain greatest sum work (and work is defined as the target specified in the bits header) is the correct one. What you are suggesting would harm convergence, especially in an adversarial model— as CJYP notes.  Imagine nodes choose the lowest hash in a race. Say you find an unusually rare block, since you are sure you'll win any equal length race instead of announcing the block you keep it secret until you hear competition in the network.

Even absent adversarial miners, lowest hash is less stable and less safe for 1-confirm transactions since the network is not synchronous some miners can just be late to report and late to switch. Right now a few seconds after you've seen a block and not seen any competition it's fairly likely that the block will not be orphaned, but with lower-hash-wins it would be less likely, moreso when you consider miners wouldn't have anywhere near as much incentive to optimize for block forwarding.

 

it immediately ends the current situation where it is more profitable to mine blocks with less transactions

Miners don't actually give a darn, otherwise they'd do the thing P2Pool has done for years and would setup the ability to relay blocks taking advantage of the transactions sent first. (Which you can get for all blocks running the relay node client, http://sourceforge.net/p/bitcoin/mailman/message/32676543/)