7

Every time a new block is added on top of block chain, the miners have to restart their work because the next block has to have a proper reference to previous block.

Let's suppose that there is some nonce for each block such that there is also sufficiently small hash (smaller than target). In general, there are 2256 possible hashes. Let the target be t. The target can be also understand as a number of acceptable hashes. So there is t / 2256 probability to find a proper hash in each try i.e. to find a block.

The number of unsuccessful tries before a block follows a geometrical distribution with parameter p=t/2256. The expected value of a variable following such a distribution is EX = 1/p = 2256/t. So, each mining pool has to spend 2256/t tries in average to find a block.

How is it that concurrent mining can be efficient, providing that each time some pool publishes a new block all other pools have to restart their work and thus throw out their tries on blocks that now can't be used any more?

Note: Please be a bit detailed. I've already read explanations like: Every try has equal chance to success. But I can't get it from such short hints.

Murch
  • 75,206
  • 34
  • 186
  • 622
czerny
  • 247
  • 1
  • 5

2 Answers2

6

The number of hashes a miner has tried in the past does not affect the probability that a miner will get the correct hash in the next immediate calculation. Thus, it does not matter for the miner from an efficiency viewpoint if he starts work on a new block since the probability of getting the correct hash is exactly the same as if he kept working on the old block.

Think of this coin flip example: The first goal is to try to get heads. You failed the first several flips and than the goal changes to getting tails. The probability of you meeting your goal is still exactly the same.

k kurokawa
  • 2,072
  • 15
  • 28
  • 1
    I understand the coin flipping example. However a I see a difference between coin flipping and finding proper nonce. I think that there is finite number of all possible hashes (2^256) and finite number of acceptable hashes t. So after trying (2^256 - t) nonces I can be sure (up to hash collisions) that I met at least one proper hash. Thus although it is not possible to establish a concept of reaching to a block finding (distribution of proper hashes is random), it is possible to say that one is reaching the point when it is sure to find a block. Why is this reasoning incorrect? – czerny Jan 21 '15 at 19:05
  • 1
    Your reasoning is correct, but 2^256 is such a large number (1.15x10^77) that the difference in probability is going to be extremely small considering that the current total network hash rate is around 300 GigaHash / sec (3*10^11). – k kurokawa Jan 21 '15 at 19:20
  • @czerny, I'm not convinced what you are saying is true, because you're not guaranteed to get a different value every time, and neither are you guaranteed to ever find a nonce that hashes low enough. It's like flipping 8 coins and hoping to get the first 4 be all heads. There are only 2^8 possible outcomes, 2^4 positive outcomes, and having a fail on the previous attempt makes you no more likely to succeed on the next. – morsecoder Jan 21 '15 at 21:48
  • 4
    @czerny: Actually, while there is a finite number of 2^256 results of the hash, the number of possible inputs for the hash function is *infinite*. Therefore you cannot be sure that you have found a winner after 2^256 inputs, because you would have hit some hash results multiple times, and some never. – Murch Jan 21 '15 at 22:02
  • 3
    @Murch, right, hence you're no more likely on one try than the next. Although, technically not infinite because the block header is 80 bytes and that's the only thing you're hashing in mining. Version, hashPrevBlock, nBits, and nTime can't really change either. That leaves merkle root (32 bytes) and nonce (4 bytes). So there are really only ~2^288 possible inputs. – morsecoder Jan 21 '15 at 22:13
  • In other words: To establish a term reaching (to point where at least one proper nonce is find) it is necessary to have a collision free hash function (which used sha256 is not) and an assurance that these exists a nonce such that block hash is smaller than target (there can't be such insurance). Hence finding a proper hash is exactly like coin flipping with one side of coin lighter. Correct? – czerny Jan 21 '15 at 22:25
  • @StephenM347 I'm not much convinced about the flipping 8 coins analogy. The probability of success in one toss is p=2^4/2^8. Probability of success if one tries long enough is q=lim n->inf (1-(1-p)^n)=1. So there is always chance to success. However in the block hashing there might be no suitable nonce so there might be cases when there is no change for success. – czerny Jan 21 '15 at 22:48
  • 3
    @czerny: Even if there is no nonce that works, you can switch around the order of the transactions, change the extra nonce, wait one second to get a new time, and so forth, so the space searched is much bigger. Also see: How can we be sure that a new block will be found? – Murch Jan 21 '15 at 22:58
  • I kind of see what you are saying @czerny, because there are an unlimited number of tries in the coin flipping game, but a finite number of tries (2^(36*8) ish) in mining. So, yes, I see that the analogy is not perfect, but I don't see any reason why that would change the probability of success from trial to trial. – morsecoder Jan 22 '15 at 00:28
4

An analogy for mining would be the following:

You are at a lottery booth. The lottery booth has 1,000 lottery tickets in a bowl (which are always mixed perfectly). There is only one ticket with a prize in the bowl. Every time somebody buys one lottery ticket, the booth owner prints a new ticket and adds it to the bowl, replacing a loser with a new losing ticket, and a winner with a winning ticket, so that there is always 1 winning ticket and 999 losing tickets in the bowl.

Whenever somebody buys a ticket, chances are 1 in 1,000 that he wins.

You might win with your first ticket, but you might win with your 10,000th.

As you already mentioned, every try at finding a new block has an equal chance of being the winning ticket. That means that there is no such thing as "progress towards the block". It either works or it doesn't.

So now, somebody found a block. If people keep mining on the old block, they would have to find two blocks in a row in order to profit, because they would have to find one to catch up, and another to overtake the current best chain. Rather they will just want to compete for the next block again!

Mining is not supposed to be efficient. Mining is supposed to be inefficient, in that it aims to prove that a sufficient amount of computational work has been expended to protect the network from being subverted.

Community
  • 1
Murch
  • 75,206
  • 34
  • 186
  • 622
  • Does this mean that computing private parallel branch is computationally easier then computing public blokchain because there would be no competing? (I understand that computing private branch in hope that it will become longer than main chain requires improbably large amount of computational power. Just theoretical question.) – czerny Jan 21 '15 at 18:49
  • Based on @kaykurokawa's comment I would a bit reword the analogy. There are so many bowls that the probability of picking the winning one changes just negligibly by removing some bowls. – czerny Jan 21 '15 at 19:41
  • @czerny: Well, if you'd want the right numbers, the bowl should have 2^256 tickets, and there'd be target winning tickets among that. You'd then start a new bowl every time somebody wins a bowl. – Murch Jan 21 '15 at 21:58