Satoshi writes at the bottom of page 3 of his white paper that "If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer." It seems here that the correct chain is the longest one, although maybe satoshi was just being a little careless with phrasing.

However, I have read other places that nodes choose the correct chain in Bitcoin by selecting the chain that represents the most work (or, in other words, the chain that would be hardest to undo). I'll call this the strongest chain. This is not necessarily the same as the longest chain since, for example, it is conceivable to have a block which took many more hashes to find a valid nonce than two other blocks with a much easier difficulty level. This stack exchange is one place that I have read this.

Question 1: Which is the correct method that nodes use to determine the correct chain, longest chain or strongest chain?

My second question is more relevant if the answer to question 1 is that the correct chain is the strongest chain. It relates to orphaned blocks.

If the correct chain is the one that represents the most work then why are orphaned blocks such a problem? It seems like if a node solves a block and broadcasts it then everyone will know about it in a matter of seconds and then can start mining on the new block without any wasted work. Even if 2 miners solve a block at (near to) the same time, most blocks will see the two new blocks and choose the one with the lower header hash (because it is harder to find lower hashes). It seems that the nodes should come to a consensus in a matter of seconds then, if the correct chain is chosen by strongest (rather than longest) chain. The only time that a miner could spend working on the wrong chain would be time spent mining between receiving a solved block which is soon after replaced by a different solved block with a slightly lower hash. How long could that be, 10 sec?

Question 2: Are orphaned blocks a big problem for miners? If the block generation time were 1 minute, instead, would orphaned blocks be a much bigger problem?

up vote 9 down vote accepted

The "longest" chain is the one with the most work. A chain's work is equal to the expected number of hashes it would take for someone to replicate a chain of the same number of blocks and the exact same difficulty steps. So currently each block adds about 266 work to the chain because it takes on average ~266 hashes to solve a block with the current difficulty. Blocks with less difficulty add less work. (The current total chain work is around 280.) However, two blocks in the same difficulty period always add the same amount of work to the chain. A block with a lower hash is not considered better than one with a higher hash.

Satoshi didn't initially realize that choosing the correct chain by just counting blocks allows for some extremely easy attacks. Version 0.1 just counted blocks. That's why the paper just says "longest". The idea of "chain work" was added a little later.

Resolving orphans as you suggest might actually make orphans more likely because miners would be incentivized in some cases to try replacing the most recent block rather than extending it, especially right before a big difficulty adjustment or when the most recent block contains a lot of fees.

Orphaned blocks happen every now and then. Eligius reports around 2% orphaned blocks. They would indeed be much more common if the target time was 1 minute since blocks would be generated faster and there would therefore be more opportunity for conflicts between blocks.

  • Although it might make orphans more likely, wouldn't choosing the correct chain this way minimize the net effect of orphans? Because, right now, if someone gets a block broadcasted to them which will eventually not be the correct block then they will waste the whole 10 minutes mining that block until the next block is solved. It seems like the network would come to a consensus more quickly and only mine on the correct blocks. – StephenM347 Jul 28 '14 at 14:11
  • As to miners trying to undo blocks, it seems like rational miners wouldn't do this most of the time. Every nonce is like a lottery ticket and if they see that a new block is out, I can't see why they would keep spending their lottery tickets on mining on top of the old block rather than the new one which is more likely to be accepted. In those two cases that you mentioned, I can see why they might try to undo the most recent block (although, the fees don't really seem to be enough incentive now), but those seem like exceptions rather than the rule for what would happen. – StephenM347 Jul 28 '14 at 14:38
  • @StephenM347 Your system would also make double-spends by powerful miners easier. Currently, if you have some decent chunk of the mining power and you want to reverse a 1-confirmation transaction, you need to mine two blocks in a row. But with your system, the miner could instead just replace the latest block, which in many cases would be much easier than solving two blocks in a row (depending on the latest block's "strength"). – theymos Jul 28 '14 at 17:22
  • @StephenM347 In any case, orphans aren't much of a problem for the network, so there's no need to change things. Miners don't like orphans because it causes them to lose blocks or waste work, but making miners happy is not important. – theymos Jul 28 '14 at 17:24
  • 1
    This answer doesn't precisely define "work". The work of a block is actually defined as floor(2^256 / (target + 1)), where 'target' is the target threshold converted from the 'nBits' field of the block header. (See the GetBlockProof function in src/pow.cpp.) – Daira Hopwood Feb 4 '17 at 4:45

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.