<p>Mining is computation based, but it's not constant, it's random. Essentially, every hash calculated generates a random number. If the random number is below the target, it's valid to create a block. The probability of any single hash being low enough is minuscule (you have a better chance of winning the lottery several times in a row), but that's why you need to calculate a lot of hashes. The actual merkle tree makes no difference as long as the tree itself is valid. Miners don't have any obligation to include all transactions in the mempool, so they typically will submit blocks whenever they find a valid hash.</p>

<p>So really, the updates to the merkle tree don't actually matter. In fact, it can be helpful since there are more nonces to try.</p>

CC BY-SA 3.0
2016-09-09T11:42:08.057Z
Could you explain how it is helpful, and how it means more nonces to try? Preferably with an example.
BlockChange
CC BY-SA 3.0
2016-09-08T15:44:18.463Z
2016-09-08T15:44:18.463Z
Jimmy Song
<p>Miners choose which transactions to include in their blocks. So they don't <em>have</em> to continually incorporate newly arrived transactions into the blocks they are trying. They can if they want, for example to take advantage of collecting possibly higher transaction fees associated with new transactions.</p>

CC BY-SA 3.0
2016-09-08T20:05:04.633Z
2016-09-08T20:05:04.633Z
Greg Hewgill
<p>I understood that when a new transaction comes in, the miners have to start over, or at least change their merkle-tree to include the new transaction, essentially starting from scratch again.</p>

<p>If I look a the real-time transactions on <a href="https://blockchain.info/" rel="nofollow">https://blockchain.info/</a>, how could miners ever make a block when there is never a break?</p>

<p>Unless you define a break as a few microseconds, and since every second you can calculate I believe billions of possible hashes, I still find it hard to grasp how a new block gets "chosen" or verified in human understandable terms.</p>

CC BY-SA 3.0
2016-09-08T15:25:30.970Z
Every new hash has equal probability of success, regardless of whether it's the first hash tried on a given block or whether there have been millions before.  "Restarting" isn't a meaningful concept; you're effectively "restarting" billions of times a second anyway, so practically nothing is lost by updating the header with the new transaction.
Nate Eldredge
CC BY-SA 3.0
2016-09-09T11:46:56.157Z
@NateEldredge Let's say you've tried a 1000 nonces without finding a block, so you know those 1000 nonces aren't it, at least for the current block. But if anything changes (ie the hash), then it has to start over in the sense that you don't have a 1000 known wrong nonces, but 0. But I think I understand your point that probability-wise there is not much of a difference.
BlockChange
CC BY-SA 3.0
2016-09-09T11:54:33.723Z
Nope. I am saying there is *zero* difference.  Knowing 1000 nonces that don't work is *useless information*; it has absolutely no bearing on the probability of the next nonce working.  Note there is no guarantee that any nonce works at all; you could have tried all but one of the 2^32 possible nonces for a block, and the probability of the last one working is still the same as for the first one you tried: 1 in (difficulty * 2^32).  (Indeed, for any given block, it's extremely unlikely that *any* of the 2^32 possible nonce values work.)
Nate Eldredge
CC BY-SA 3.0
2016-09-09T11:56:58.493Z
Consider the following thought experiment.  I have a red die with a billion sides. I roll it and ask you to guess the number.  If you're right, you win.  If not, I **roll again** and ask you guess the new number.  Since we re-roll every time, having 1000 incorrect guesses doesn't help or hurt your chances on the next roll.  And if after 1000 plays, I throw away the red die and start using a billion-sided green die, you haven't lost any "progress".
Nate Eldredge
CC BY-SA 3.0
2016-09-09T11:57:58.303Z
If the nonce range is let's say 1-1000000 (I think there's an upper limit in bitcoin?) then you probability increases, per probability, if you know what I mean. I understand that it's possible that no nonce works at all, but then you are getting closer to using an extraNonce, or perhaps the difficulty decreasing?
BlockChange
CC BY-SA 3.0
2016-09-09T12:00:32.133Z
No!  The behavior of the hash function is such that every new nonce tried is a fresh roll of the die.  "Starting over" costs **nothing** because there is **no progress** to be lost.
Nate Eldredge
CC BY-SA 3.0
2016-09-09T12:00:33.627Z
@NateEldredge, ok, but in this though experiment, we can't roll the same side of the dice twice, because you know that wasn't the answer. But I guess your point is that with dice you don't have a choice. But I ask you with a nonce you do right? Or do you mean you roll that dice per nonce?
BlockChange
CC BY-SA 3.0
2016-09-09T12:05:44.213Z
@NateEldredge, Ok, I think I understand what you mean. So essentially "restarting" mining does not matter, using the same nonce with a different hash is useless and has no relation to its outcome. (But at the same time trying the same nonce over and over on the same hash is not going to change anything obviously. But each time you use a different nonce it will reset you chances)
BlockChange
<mining-theory><transaction-selection><consensus><merkle-tree>
Restarting mining on new transaction
BlockChange
# Restarting mining on new transaction

(Asked by: username_0 on 2016-09-08)

I understood that when a new transaction comes in, the miners have to start over, or at least change their merkle-tree to include the new transaction, essentially starting from scratch again.

If I look a the real-time transactions on <https://blockchain.info/>, how could miners ever make a block when there is never a break?

Unless you define a break as a few microseconds, and since every second you can calculate I believe billions of possible hashes, I still find it hard to grasp how a new block gets "chosen" or verified in human understandable terms.

**Tags:** mining-theory, transaction-selection, consensus, merkle-tree

> **Comments:**
> **username_1**: Every new hash has equal probability of success, regardless of whether it's the first hash tried on a given block or whether there have been millions before.  "Restarting" isn't a meaningful concept; you're effectively "restarting" billions of times a second anyway, so practically nothing is lost by updating the header with the new transaction.  
> **username_0**: @username_1 Let's say you've tried a 1000 nonces without finding a block, so you know those 1000 nonces aren't it, at least for the current block. But if anything changes (ie the hash), then it has to start over in the sense that you don't have a 1000 known wrong nonces, but 0. But I think I understand your point that probability-wise there is not much of a difference.  
> **username_1**: Nope. I am saying there is *zero* difference.  Knowing 1000 nonces that don't work is *useless information*; it has absolutely no bearing on the probability of the next nonce working.  Note there is no guarantee that any nonce works at all; you could have tried all but one of the 2^32 possible nonces for a block, and the probability of the last one working is still the same as for the first one you tried: 1 in (difficulty * 2^32).  (Indeed, for any given block, it's extremely unlikely that *any* of the 2^32 possible nonce values work.)  
> **username_1**: Consider the following thought experiment.  I have a red die with a billion sides. I roll it and ask you to guess the number.  If you're right, you win.  If not, I **roll again** and ask you guess the new number.  Since we re-roll every time, having 1000 incorrect guesses doesn't help or hurt your chances on the next roll.  And if after 1000 plays, I throw away the red die and start using a billion-sided green die, you haven't lost any "progress".  
> **username_0**: If the nonce range is let's say 1-1000000 (I think there's an upper limit in bitcoin?) then you probability increases, per probability, if you know what I mean. I understand that it's possible that no nonce works at all, but then you are getting closer to using an extraNonce, or perhaps the difficulty decreasing?  
> **username_1**: No!  The behavior of the hash function is such that every new nonce tried is a fresh roll of the die.  "Starting over" costs **nothing** because there is **no progress** to be lost.  
> **username_0**: @username_1, ok, but in this though experiment, we can't roll the same side of the dice twice, because you know that wasn't the answer. But I guess your point is that with dice you don't have a choice. But I ask you with a nonce you do right? Or do you mean you roll that dice per nonce?  
> **username_0**: @username_1, Ok, I think I understand what you mean. So essentially "restarting" mining does not matter, using the same nonce with a different hash is useless and has no relation to its outcome. (But at the same time trying the same nonce over and over on the same hash is not going to change anything obviously. But each time you use a different nonce it will reset you chances)  

---

## 2 answers

### Answer by username_2 on 2016-09-08. Score: 1

Mining is computation based, but it's not constant, it's random. Essentially, every hash calculated generates a random number. If the random number is below the target, it's valid to create a block. The probability of any single hash being low enough is minuscule (you have a better chance of winning the lottery several times in a row), but that's why you need to calculate a lot of hashes. The actual merkle tree makes no difference as long as the tree itself is valid. Miners don't have any obligation to include all transactions in the mempool, so they typically will submit blocks whenever they find a valid hash.

So really, the updates to the merkle tree don't actually matter. In fact, it can be helpful since there are more nonces to try.

> **Comments:**
> **username_0**: Could you explain how it is helpful, and how it means more nonces to try? Preferably with an example.  

---

### Answer by username_3 on 2016-09-08. Score: 1

Miners choose which transactions to include in their blocks. So they don't *have* to continually incorporate newly arrived transactions into the blocks they are trying. They can if they want, for example to take advantage of collecting possibly higher transaction fees associated with new transactions.


---

