<p>Under the current system, miners never wait. Transaction fees are too small of a part of the total block reward for people to bother with that.</p>

CC BY-SA 3.0
2015-09-05T04:50:11.637Z
You mean the miners are always solving a block with whatever previous transactions they had queued?
Peter Mel
CC BY-SA 3.0
2015-09-11T01:11:02.167Z
@PeterMel Yes, that's correct.
Nick ODell
CC BY-SA 3.0
2015-09-05T04:42:29.627Z
2015-09-05T04:42:29.627Z
Nick ODell
<blockquote>
  <p>I am confused about whether a miner chooses to wait for more transactions (more fees) or starts as soon as it receives the first transaction from the network. Once a miner has started calculating the hashes, it will queue the new transactions, correct?</p>
</blockquote>

<p>Yes, they can begin mining as soon as they see the previous, and update the block template with new transactions they see whenever they would like. The early Satoshi client updated the template every few seconds, modern miners seem to do it every half a minute or longer depending on the software. There's no advantage for them to update the block template other than that they might get more fees if they do, if they miss transactions there's no real harm done. </p>

<blockquote>
  <p>If I am lucky to find the solution for a block with just one transaction, but someone else finds the solution for a block with my transaction and one more, so he wins, correct?</p>
</blockquote>

<p>No, this isn't correct, no miners break ties with the number of transactions in a block. First seen is generally going to be the behavior most people use if they can see two competing blocks at an equal height with an equal difficulty target. If they did tie break with the number of transactions then miners could make blocks stuffed with their own fake ones and always win any races.  </p>

<blockquote>
  <p>So the more transactions there are in a block the more difficult it is to solve the hashing puzzle, is that correct?</p>
</blockquote>

<p>No, the header of a block is always 80 bytes long irrespective of the number of transactions the block actually contains. This is because the block header only includes a hash of the transactions, rather than the transaction contents themselves. The difficulty is the same for a block with no transactions other than the one paying the miner or a block with thousands. </p>

<blockquote>
  <p>Can someone clarify how this transaction grouping is done by mining nodes?</p>
</blockquote>

<p>Hard to answer this because most pools run completely custom software, they have their own criteria and their own optimizations which they perform. Generally they will collect all valid transactions which have the fee they want to accept, and assemble them into a block of the maximum size they wish to create, any which are not included are left in the memory pool for later or for someone else to mine. </p>

CC BY-SA 3.0
2015-09-05T05:44:47.293Z
Thank you  very much for your clear explanation. If you don't mind, could you answer this other question related to this one: http://bitcoin.stackexchange.com/questions/40399/how-can-a-block-be-considered-more-difficult-to-solve-hash-than-another-one
Peter Mel
CC BY-SA 3.0
2015-09-05T05:35:59.413Z
2015-09-05T09:25:25.073Z
2015-09-05T09:25:25.073Z
Claris
<p>I am confused about whether a miner chooses to <em>wait for more transactions</em> (more fees) or starts as soon as it receives the first transaction from the network. Once a miner has started calculating the hashes, it will queue the new transactions, correct?</p>

<p>My confusion is: each miner node will be calculating the hash for a different block. Some will have more transactions than others. Does it matter?</p>

<p>If I am lucky to find the solution for a block with just one transaction, but someone else finds the solution for a block with my transaction and one more, so he wins, correct?</p>

<p>So the more transactions there are in a block the more difficult it is to solve the hashing puzzle, is that correct? If yes, why?</p>

<p>Can someone clarify how this transaction grouping is done by mining nodes?</p>

<blockchain><block><mining-technical-details>
When does a miner decide to stop collecting transactions and start calculating hashes to try to win?
Peter Mel
# When does a miner decide to stop collecting transactions and start calculating hashes to try to win?

(Asked by: username_0 on 2015-09-05)

I am confused about whether a miner chooses to *wait for more transactions* (more fees) or starts as soon as it receives the first transaction from the network. Once a miner has started calculating the hashes, it will queue the new transactions, correct?

My confusion is: each miner node will be calculating the hash for a different block. Some will have more transactions than others. Does it matter?

If I am lucky to find the solution for a block with just one transaction, but someone else finds the solution for a block with my transaction and one more, so he wins, correct?

So the more transactions there are in a block the more difficult it is to solve the hashing puzzle, is that correct? If yes, why?

Can someone clarify how this transaction grouping is done by mining nodes?

**Tags:** blockchain, block, mining-technical-details


---

## 2 answers

### Answer by username_2 on 2015-09-05. Score: 9 | Accepted answer

> I am confused about whether a miner chooses to wait for more transactions (more fees) or starts as soon as it receives the first transaction from the network. Once a miner has started calculating the hashes, it will queue the new transactions, correct?

Yes, they can begin mining as soon as they see the previous, and update the block template with new transactions they see whenever they would like. The early Satoshi client updated the template every few seconds, modern miners seem to do it every half a minute or longer depending on the software. There's no advantage for them to update the block template other than that they might get more fees if they do, if they miss transactions there's no real harm done.

> If I am lucky to find the solution for a block with just one transaction, but someone else finds the solution for a block with my transaction and one more, so he wins, correct?

No, this isn't correct, no miners break ties with the number of transactions in a block. First seen is generally going to be the behavior most people use if they can see two competing blocks at an equal height with an equal difficulty target. If they did tie break with the number of transactions then miners could make blocks stuffed with their own fake ones and always win any races.

> So the more transactions there are in a block the more difficult it is to solve the hashing puzzle, is that correct?

No, the header of a block is always 80 bytes long irrespective of the number of transactions the block actually contains. This is because the block header only includes a hash of the transactions, rather than the transaction contents themselves. The difficulty is the same for a block with no transactions other than the one paying the miner or a block with thousands.

> Can someone clarify how this transaction grouping is done by mining nodes?

Hard to answer this because most pools run completely custom software, they have their own criteria and their own optimizations which they perform. Generally they will collect all valid transactions which have the fee they want to accept, and assemble them into a block of the maximum size they wish to create, any which are not included are left in the memory pool for later or for someone else to mine.

> **Comments:**
> **username_0**: Thank you  very much for your clear explanation. If you don't mind, could you answer this other question related to this one: http://bitcoin.stackexchange.com/questions/40399/how-can-a-block-be-considered-more-difficult-to-solve-hash-than-another-one  

---

### Answer by username_1 on 2015-09-05. Score: 1

Under the current system, miners never wait. Transaction fees are too small of a part of the total block reward for people to bother with that.

> **Comments:**
> **username_0**: You mean the miners are always solving a block with whatever previous transactions they had queued?  
> **username_1**: @username_0 Yes, that's correct.  

---

