<blockquote>
  <ol start="4">
  <li>Lets say we have just put a block on the blockchain and there are no blocks at the moment that miners mine. Now miners start forming new blocks and try to guess new hash values. The miners are putting transactions into their formed block (with a hash guess)? Which of the unconfirmed transactions do they put into the block (all unconfirmed or a subset)?</li>
  </ol>
</blockquote>

<p>Miners will select transactions to include based upon transaction fees. In Bitcoin Core, this transaction selection is done as follows: Group up transactions into packages, a package consists of a transaction and its unconfirmed ancestors and descendants (some packages may just be 1 transaction, others more). Then calculate the total fee rate paid by a package and sort the packages by fee rate. Select transactions by going down the list of packages and choosing each package until the weight of all of the transactions (as defined by <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#block-size" rel="nofollow noreferrer">BIP 141</a>) cannot allow any more transactions to be included (i.e. add packages until the weight exceeds the limit, then remove what was just added and add the next one, etc. until no transactions left to add).</p>

<p>There will often be more unconfirmed transactions than can fit in a block, so miners will only select a subset of unconfirmed transactions.</p>

<blockquote>
  <ol start="5">
  <li>Is putting a transaction into a block a way of stating that transaction has been validated? How does this guarantee the transaction miner put in the block is valid?</li>
  </ol>
</blockquote>

<p>It is not. A block could contain invalid transactions and the block (and those invalid transactions) would be invalid. A full node must check that a block is valid. They do this by checking the block header is valid, the coinbase transaction is valid, and all transactions in the block are valid. Just because a transaction is found in a block does not mean that it is necessarily valid, and if it is not, the block is invalid and should be rejected.</p>

CC BY-SA 3.0
2017-10-21T18:04:21.700Z
You can have the next few, I'm quitting for the day :-)
Nate Eldredge
CC BY-SA 3.0
2017-10-21T18:21:18.413Z
A lot of subquestions. Have to put some of them into separate questions. Damn doesnt let me post that often :D
croraf
CC BY-SA 3.0
2017-10-21T18:29:35.897Z
You say if a block with correct header is put at the end of the chain but with invalid transaction the block itself is invalid. Does this mean that then anyone can use the same block with correct transactions and throw it on the chain again?
croraf
CC BY-SA 3.0
2017-10-21T18:31:24.063Z
It would not be the same block because the invalid transaction would not be there and likely the nonces would be different because removing or replacing the invalid transaction (or changing it in any way) will change the block hash. But yes, there can be another block at the same height which contains almost exactly the same transactions.
Ava Chow
CC BY-SA 3.0
2017-10-21T18:33:00.620Z
So the solutions (you call them nonces?) depend on the transactions included in the block?
croraf
CC BY-SA 3.0
2017-10-21T18:34:40.090Z
The solutions are not nonces. Nonces are part of the data that is hashed and are what is commonly changed when trying to find a block hash (the solution) that is less than the target. The data that is hashed for the block hash includes the hash of all of the transactions in the block, so changing the transactions will also change the block hash.
Ava Chow
CC BY-SA 3.0
2018-01-15T08:21:00.480Z
Is it possible to add transaction to a block *without* it's descendants? I can't seem to find the answer to this. If it *is* possible, you would have to consider the packages with only the ancestors, and the packages with both the ancestors and the descendants, when selecting the transactions.
gijswijs
CC BY-SA 3.0
2018-01-15T17:26:41.803Z
It is possible to add a transaction without it's descendants. There is nothing that prevents a miner from doing so. It is not possible to add a transaction without it's ancestors. Either the ancestors must already be in a previous block, or they must be included in the same block and come before the transaction in question.
Ava Chow
CC BY-SA 3.0
2017-10-21T18:02:57.530Z
2017-10-21T18:02:57.530Z
Ava Chow
<p>4: As far as the protocol is concerned, it is completely at the miner's discretion which transactions to include.  It is legal if the miner chooses to include no transactions at all (other than the coinbase transaction which is required), and some miners actually do this (it means that the block is small and can be relayed quickly, which slightly decreases the chance that it will be orphaned).</p>

<p>Most miners will include as many unconfirmed transactions as possible, up to the block size limit, preferring those which have the highest fees.  They may automatically exclude those which transfer a very small value (so-called "dust") or whose fee is below some threshold. </p>

<p>5: The miner is expected to verify that every transaction in his block is valid (outputs not already spent, valid ECDSA signatures, etc).  When he finds a nonce which attains the target hash and submits his block to the network, other nodes will attempt to similarly verify the transactions in it, and if they are not all valid the entire block will be rejected (i.e. other miners will not use this block's hash as the "previous block" in their own mining).  However, mining is not necessary for this sort of verification, since non-mining nodes will also do this verification, and refuse to recognize any transactions that don't pass.</p>

CC BY-SA 3.0
2017-10-21T18:27:54.503Z
Sorry, why would I not put as many transactions in the block as it fits?
croraf
CC BY-SA 3.0
2017-10-21T18:38:13.207Z
Does the difficulty of "solving hash" depends on the number of transactions in the block (or maybe some other transaction related weight)?
croraf
CC BY-SA 3.0
2017-10-21T20:58:25.063Z
https://en.bitcoin.it/wiki/Block_hashing_algorithm below the table it states that the difficulty is the same irrespective of transactions if I read correctly.
croraf
CC BY-SA 3.0
2017-10-21T18:04:00.160Z
2017-10-21T18:04:00.160Z
Nate Eldredge
<p>Why are transactions grouped into blocks (PART 3)?</p>

<ol start="4">
<li><p>Lets say we have just put a block on the blockchain. Now miners start forming new blocks and try to guess new hash values. The miners are putting transactions into their formed block (with a hash guess)? Which of the unconfirmed transactions do they put into the block (all unconfirmed or a subset)? </p></li>
<li><p>Is putting a transaction into a block a way of stating that transaction has been validated? How does this guarantee the transaction, miner put in the block, is valid?</p></li>
</ol>

<block><mining-theory>
Why are transactions grouped into blocks? (how are transactions put into blocks)
croraf
# Why are transactions grouped into blocks? (how are transactions put into blocks)

(Asked by: username_0 on 2017-10-21)

Why are transactions grouped into blocks (PART 3)?

4. Lets say we have just put a block on the blockchain. Now miners start forming new blocks and try to guess new hash values. The miners are putting transactions into their formed block (with a hash guess)? Which of the unconfirmed transactions do they put into the block (all unconfirmed or a subset)?
5. Is putting a transaction into a block a way of stating that transaction has been validated? How does this guarantee the transaction, miner put in the block, is valid?

**Tags:** block, mining-theory


---

## 2 answers

### Answer by username_1 on 2017-10-21. Score: 2 | Accepted answer

> 4. Lets say we have just put a block on the blockchain and there are no blocks at the moment that miners mine. Now miners start forming new blocks and try to guess new hash values. The miners are putting transactions into their formed block (with a hash guess)? Which of the unconfirmed transactions do they put into the block (all unconfirmed or a subset)?

Miners will select transactions to include based upon transaction fees. In Bitcoin Core, this transaction selection is done as follows: Group up transactions into packages, a package consists of a transaction and its unconfirmed ancestors and descendants (some packages may just be 1 transaction, others more). Then calculate the total fee rate paid by a package and sort the packages by fee rate. Select transactions by going down the list of packages and choosing each package until the weight of all of the transactions (as defined by [BIP 141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#block-size)) cannot allow any more transactions to be included (i.e. add packages until the weight exceeds the limit, then remove what was just added and add the next one, etc. until no transactions left to add).

There will often be more unconfirmed transactions than can fit in a block, so miners will only select a subset of unconfirmed transactions.

> 5. Is putting a transaction into a block a way of stating that transaction has been validated? How does this guarantee the transaction miner put in the block is valid?

It is not. A block could contain invalid transactions and the block (and those invalid transactions) would be invalid. A full node must check that a block is valid. They do this by checking the block header is valid, the coinbase transaction is valid, and all transactions in the block are valid. Just because a transaction is found in a block does not mean that it is necessarily valid, and if it is not, the block is invalid and should be rejected.

> **Comments:**
> **username_2**: You can have the next few, I'm quitting for the day :-)  
> **username_0**: A lot of subquestions. Have to put some of them into separate questions. Damn doesnt let me post that often :D  
> **username_0**: You say if a block with correct header is put at the end of the chain but with invalid transaction the block itself is invalid. Does this mean that then anyone can use the same block with correct transactions and throw it on the chain again?  
> **username_1**: It would not be the same block because the invalid transaction would not be there and likely the nonces would be different because removing or replacing the invalid transaction (or changing it in any way) will change the block hash. But yes, there can be another block at the same height which contains almost exactly the same transactions.  
> **username_0**: So the solutions (you call them nonces?) depend on the transactions included in the block?  
> **username_1**: The solutions are not nonces. Nonces are part of the data that is hashed and are what is commonly changed when trying to find a block hash (the solution) that is less than the target. The data that is hashed for the block hash includes the hash of all of the transactions in the block, so changing the transactions will also change the block hash.  
> **username_3**: Is it possible to add transaction to a block *without* it's descendants? I can't seem to find the answer to this. If it *is* possible, you would have to consider the packages with only the ancestors, and the packages with both the ancestors and the descendants, when selecting the transactions.  
> **username_1**: It is possible to add a transaction without it's descendants. There is nothing that prevents a miner from doing so. It is not possible to add a transaction without it's ancestors. Either the ancestors must already be in a previous block, or they must be included in the same block and come before the transaction in question.  

---

### Answer by username_2 on 2017-10-21. Score: 1

4: As far as the protocol is concerned, it is completely at the miner's discretion which transactions to include. It is legal if the miner chooses to include no transactions at all (other than the coinbase transaction which is required), and some miners actually do this (it means that the block is small and can be relayed quickly, which slightly decreases the chance that it will be orphaned).

Most miners will include as many unconfirmed transactions as possible, up to the block size limit, preferring those which have the highest fees. They may automatically exclude those which transfer a very small value (so-called "dust") or whose fee is below some threshold.

5: The miner is expected to verify that every transaction in his block is valid (outputs not already spent, valid ECDSA signatures, etc). When he finds a nonce which attains the target hash and submits his block to the network, other nodes will attempt to similarly verify the transactions in it, and if they are not all valid the entire block will be rejected (i.e. other miners will not use this block's hash as the "previous block" in their own mining). However, mining is not necessary for this sort of verification, since non-mining nodes will also do this verification, and refuse to recognize any transactions that don't pass.

> **Comments:**
> **username_0**: Sorry, why would I not put as many transactions in the block as it fits?  
> **username_0**: Does the difficulty of "solving hash" depends on the number of transactions in the block (or maybe some other transaction related weight)?  
> **username_0**: https://en.bitcoin.it/wiki/Block_hashing_algorithm below the table it states that the difficulty is the same irrespective of transactions if I read correctly.  

---

