<p>Mining is a series of independent attempts at finding a good hash for a block.
Since all attempts are independent from each other, modifying the block between one attempt and the other have no negative effect.</p>

CC BY-SA 3.0
2012-12-11T14:45:56.947Z
2014-01-05T13:53:15.917Z
2014-01-05T13:53:15.917Z
o0'.
<p>Just adding to the other answers. A transaction is still bound to a block and the block hash still has to match with the transaction included. However, when more transactions are added, the next attempt will create the hash of a different block. Using this new hash with the previous block will not be accepted by the network. So from what I gather, when attempting the hashing, they not only change the nonce but the data as well. The probability to succeed is the same either way. </p>

CC BY-SA 3.0
2012-12-11T20:03:52.977Z
2012-12-11T20:03:52.977Z
Jus12
<p>One small addition to the other answers:</p>

<p>When a new transaction shows up, the miner stops for a moment, adds it to the transaction list, and starts mining again.  This slows him down because for a short while, he isn't mining.  <strong>But</strong>, according to the protocol, a client is supposed to accept the transaction history that includes the most transactions.  So, if the miner doesn't stop to add new transactions, he's at risk of succeeding but then someone else succeeding with a longer transaction list.  And then he doesn't get paid.</p>

<p>Edit: Oops, I thought that I read this somewhere but looking again, I didn't.  So why does a miner have any incentive to pause his mining and recalculate the block's hash?  Unless a transaction has a fee.</p>

CC BY-SA 3.0
2013-04-02T19:54:05.240Z
Eventually a miner will increment the nonce to a point where "extranonce" is needed.  At this point a new header is generated.  Often instead of using extranonce, it's possible to add transactions, regenerate the merkle root, and start the rehashing.  Yes, outside of fees, there isn't much incentive for a miner to include a tx that has a zero or too low of a fee.  Read Microsoft's paper on "Bitcoin and red balloons" for an alternate approach
makerofthings7
CC BY-SA 3.0
2013-04-04T08:25:37.453Z
I admit, that paper was too dense for me.  Is there a shorter explanation to solve the problem: How do we cause nodes not to hoard new transactions?
Eyal
CC BY-SA 3.0
2013-04-01T21:54:17.917Z
2013-04-02T07:43:23.060Z
2013-04-02T07:43:23.060Z
Eyal
<p>You're thinking that mining a block is a single long computing process, like computing the trillionth digit of pi or something like that. This is wrong. Each attempt at solving a block takes almost no time at all, and each attempt is independent of the others. Miners make many attempts every second. Each attempt has a very small chance of solving the block. It's a lottery, not a race. Modifying the block between attempts isn't a problem.</p>

<p>Another common misconception related to this is that everyone is working on the same block. This is also false. Every miner works on a different block.</p>

CC BY-SA 3.0
2012-12-11T15:19:39.270Z
I'll add to answer the OP's last question - the binding between a transaction and the work involved in finding a block is probabilistic. You *could* find a valid block with the transaction computing just one hash. But the probability of this is negligible, and the block proves that, on average, a lot of computational work was done acknowledging this transaction.
Meni Rosenfeld
CC BY-SA 3.0
2012-12-11T14:44:41.007Z
2012-12-11T14:44:41.007Z
theymos
<p>It seems counter-intuitive that the current block can be hashed and transactions can be added to it, <a href="https://bitcointalk.org/index.php?topic=165.msg1595#msg1595">however that is what this thread indicates.</a></p>

<p>Can someone help me connect the dots (not necessarily regarding that linked network attack) and understand how something under active computation can have its underlying data (list of transactions) changed?</p>

<p>In other words, if a tx isn't "bound" to a block via hashing, how do they relate to each other?</p>

<transactions><block><hash><learning><merkle-tree>
How is it possible that transactions can be added to a block currently being mined?
makerofthings7
# How is it possible that transactions can be added to a block currently being mined?

(Asked by: username_0 on 2012-12-11)

It seems counter-intuitive that the current block can be hashed and transactions can be added to it, [however that is what this thread indicates.](https://bitcointalk.org/index.php?topic=165.msg1595#msg1595)

Can someone help me connect the dots (not necessarily regarding that linked network attack) and understand how something under active computation can have its underlying data (list of transactions) changed?

In other words, if a tx isn't "bound" to a block via hashing, how do they relate to each other?

**Tags:** transactions, block, hash, learning, merkle-tree


---

## 4 answers

### Answer by username_4 on 2012-12-11. Score: 8 | Accepted answer

You're thinking that mining a block is a single long computing process, like computing the trillionth digit of pi or something like that. This is wrong. Each attempt at solving a block takes almost no time at all, and each attempt is independent of the others. Miners make many attempts every second. Each attempt has a very small chance of solving the block. It's a lottery, not a race. Modifying the block between attempts isn't a problem.

Another common misconception related to this is that everyone is working on the same block. This is also false. Every miner works on a different block.

> **Comments:**
> **username_5**: I'll add to answer the OP's last question - the binding between a transaction and the work involved in finding a block is probabilistic. You *could* find a valid block with the transaction computing just one hash. But the probability of this is negligible, and the block proves that, on average, a lot of computational work was done acknowledging this transaction.  

---

### Answer by username_1 on 2012-12-11. Score: 4

Mining is a series of independent attempts at finding a good hash for a block.
Since all attempts are independent from each other, modifying the block between one attempt and the other have no negative effect.


---

### Answer by username_2 on 2012-12-11. Score: 3

Just adding to the other answers. A transaction is still bound to a block and the block hash still has to match with the transaction included. However, when more transactions are added, the next attempt will create the hash of a different block. Using this new hash with the previous block will not be accepted by the network. So from what I gather, when attempting the hashing, they not only change the nonce but the data as well. The probability to succeed is the same either way.


---

### Answer by username_3 on 2013-04-01. Score: -1

One small addition to the other answers:

When a new transaction shows up, the miner stops for a moment, adds it to the transaction list, and starts mining again. This slows him down because for a short while, he isn't mining. **But**, according to the protocol, a client is supposed to accept the transaction history that includes the most transactions. So, if the miner doesn't stop to add new transactions, he's at risk of succeeding but then someone else succeeding with a longer transaction list. And then he doesn't get paid.

Edit: Oops, I thought that I read this somewhere but looking again, I didn't. So why does a miner have any incentive to pause his mining and recalculate the block's hash? Unless a transaction has a fee.

> **Comments:**
> **username_0**: Eventually a miner will increment the nonce to a point where "extranonce" is needed.  At this point a new header is generated.  Often instead of using extranonce, it's possible to add transactions, regenerate the merkle root, and start the rehashing.  Yes, outside of fees, there isn't much incentive for a miner to include a tx that has a zero or too low of a fee.  Read Microsoft's paper on "Bitcoin and red balloons" for an alternate approach  
> **username_3**: I admit, that paper was too dense for me.  Is there a shorter explanation to solve the problem: How do we cause nodes not to hoard new transactions?  

---

