# How is it that concurrent miners do not subvert each other's work?

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.

• Do you not agree that every try has an equal chance to success? Or do you not understand the consequences of that? (Because that is the canonical short answer.) – David Schwartz Jan 22 '15 at 9:33
• I did not understand that every try has (exactly) an equal change to success. The discussion below and question How can we be sure that a new block will be found? helped me to clarify that. – czerny Jan 22 '15 at 9:40

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.

• 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
• 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). – kaykurokawa Jan 21 '15 at 19:20
• @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
• @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
• @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

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.

• 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