<p>Miners have a long-term investment in the health of the Bitcoin network. If Bitcoin collapses, then their expensive ASICs are worthless. Miners particularly need Bitcoins to remain valuable over the long term because their hardware produces Bitcoins over time.</p>

<p>If nobody includes transactions in blocks, then Bitcoins would be useless and therefore worthless. That would hurt the miners' long-term investment.</p>

<p>If this ever became a problem, transactions would just wind up with higher fees to encourage miners to include them. Right now, enough miners will include a transaction with a miniscule fee that there's no point in paying more.</p>

CC BY-SA 3.0
2013-06-10T07:59:18.390Z
I see. So the few additional hash computations for the Merkle tree update are probably for the "greater good" (but might get rewarded by tx fees). However mining is still exactly at same speed as without including transactions (because there is no "from scratch") - I did not realize that yesterday. Well ASICs probably would be worthless but a general purpose CPU won't. We are probably off-topic but I guess that's the motivation behind Proof of Stake (more BTC, more to lose if the network collapses).
fiction
CC BY-SA 3.0
2015-01-21T11:29:28.443Z
_"However mining is still exactly at same speed as without including transactions (because there is no "from scratch")"_ - there is a from scratch every time a transaction is added (due to a new merkle root), but because 2^32 nonces can be hashed on the header so fast, adding another transaction(s) to attempt the next round of hashes with all nonces isn't a big deal. Additionally, the timestamp in the header adds variation enough for a new group of hashing with the 2^32 nonces. Can someone confirm if this is correct. Whatever the case I've voted up the question & accepted answer, thanks!
alexkb
CC BY-SA 3.0
2013-06-10T01:33:24.707Z
2013-06-10T01:33:24.707Z
David Schwartz
<p>I think I understand the basic operation of the Bitcoin protocol.</p>

<p>Blocks are the "long-term memory" of the network used to prevent double spending (and the way the network agrees in first place). Proof of work is sort of brute-forcing the nonce so that the hash has at least the desired number of zeros. When a dishonest node generates a new block other nodes will refuse it should it contain transactions that were not seen by them, so the network will "converge".</p>

<p>I guess the transactions need to be included in that PoW (or else it would be simple to alter them afterwards). So every time a new transaction is seen it will require the miner to start brute-forcing "from scratch"? I read some sort of tree is formed, so it actually doesn't mean the input to the hash function gets longer, but still every transaction will change the "root value", won't it?</p>

<p>Why would a miner even bother to include all transactions that occurred on the network (given that transaction fees are minimal)? There is no lower limit on the tx number per block (perhaps in that time there were really no transactions). It would be simpler for them to just include perhaps one and then use their (CPU) time to solve the puzzle and earn the reward.</p>

<p>There must be some sort of thing in the Bitcoin design which I don't get yet...</p>

CC BY-SA 3.0
2013-06-10T07:47:16.497Z
I've probably fallen for the "gambler's fallacy". The probability that the next calculation will win is the same no matter whether I change just the nonce or something else changes in the block. On average is takes that many tries to get a correct solution.
fiction
CC BY-SA 3.0
2013-07-22T07:11:59.450Z
Your answer is based on many misconceptions. For one thing, 2^31 is half of 2^32, not 2^16. For another thing, a typical miner will try all 2^32 possible nonces in a second or so. Lastly, your chances of finding a working nonce are completely independent of how many prior successes or failures you've had. It may be that no nonce in the 2^32 possible nonces work. It may be that ten of them work. Each nonce is an independent trial. Typical miners won't interrupt a set of 2^32 nonces just because of a new transaction, but a few seconds later, their next run will use the new transaction.
David Schwartz
<transactions><block><transaction-selection>
What is the motivation for miners to include all recent transactions in a block?
fiction
# What is the motivation for miners to include all recent transactions in a block?

(Asked by: username_0 on 2013-06-09)

I think I understand the basic operation of the Bitcoin protocol.

Blocks are the "long-term memory" of the network used to prevent double spending (and the way the network agrees in first place). Proof of work is sort of brute-forcing the nonce so that the hash has at least the desired number of zeros. When a dishonest node generates a new block other nodes will refuse it should it contain transactions that were not seen by them, so the network will "converge".

I guess the transactions need to be included in that PoW (or else it would be simple to alter them afterwards). So every time a new transaction is seen it will require the miner to start brute-forcing "from scratch"? I read some sort of tree is formed, so it actually doesn't mean the input to the hash function gets longer, but still every transaction will change the "root value", won't it?

Why would a miner even bother to include all transactions that occurred on the network (given that transaction fees are minimal)? There is no lower limit on the tx number per block (perhaps in that time there were really no transactions). It would be simpler for them to just include perhaps one and then use their (CPU) time to solve the puzzle and earn the reward.

There must be some sort of thing in the Bitcoin design which I don't get yet...

**Tags:** transactions, block, transaction-selection

> **Comments:**
> **username_0**: I've probably fallen for the "gambler's fallacy". The probability that the next calculation will win is the same no matter whether I change just the nonce or something else changes in the block. On average is takes that many tries to get a correct solution.  
> **username_1**: Your answer is based on many misconceptions. For one thing, 2^31 is half of 2^32, not 2^16. For another thing, a typical miner will try all 2^32 possible nonces in a second or so. Lastly, your chances of finding a working nonce are completely independent of how many prior successes or failures you've had. It may be that no nonce in the 2^32 possible nonces work. It may be that ten of them work. Each nonce is an independent trial. Typical miners won't interrupt a set of 2^32 nonces just because of a new transaction, but a few seconds later, their next run will use the new transaction.  

---

## 1 answers

### Answer by username_1 on 2013-06-10. Score: 11 | Accepted answer

Miners have a long-term investment in the health of the Bitcoin network. If Bitcoin collapses, then their expensive ASICs are worthless. Miners particularly need Bitcoins to remain valuable over the long term because their hardware produces Bitcoins over time.

If nobody includes transactions in blocks, then Bitcoins would be useless and therefore worthless. That would hurt the miners' long-term investment.

If this ever became a problem, transactions would just wind up with higher fees to encourage miners to include them. Right now, enough miners will include a transaction with a miniscule fee that there's no point in paying more.

> **Comments:**
> **username_0**: I see. So the few additional hash computations for the Merkle tree update are probably for the "greater good" (but might get rewarded by tx fees). However mining is still exactly at same speed as without including transactions (because there is no "from scratch") - I did not realize that yesterday. Well ASICs probably would be worthless but a general purpose CPU won't. We are probably off-topic but I guess that's the motivation behind Proof of Stake (more BTC, more to lose if the network collapses).  
> **username_2**: _"However mining is still exactly at same speed as without including transactions (because there is no "from scratch")"_ - there is a from scratch every time a transaction is added (due to a new merkle root), but because 2^32 nonces can be hashed on the header so fast, adding another transaction(s) to attempt the next round of hashes with all nonces isn't a big deal. Additionally, the timestamp in the header adds variation enough for a new group of hashing with the 2^32 nonces. Can someone confirm if this is correct. Whatever the case I've voted up the question & accepted answer, thanks!  

---

