<blockquote>
<p>How does miner order transactions if two are unrelated? e.g., A pays C, X pays Y. I assume changing the order in the block will change the hash, so I am curious how Bitcoin code combines them in which order.</p>
</blockquote>
<p>Transactions can be ordered in a block in any way a miner wishes to so long as a transaction which spends an output created by another transaction in that block is placed after its parent. This order does matter for the block hash, and so once the order is decided, it is fixed for that block.</p>
<p>Many miners use Bitcoin Core's block template functionality to build their blocks. This will choose the transactions to include, and an order to include them in. The way Bitcoin Core chooses transactions is to first group related transactions together as packages, then order packages by the feerate paid by the package. Then packages are simply selected in order from highest to lowest until the block weight maximum is reached. (The actual selection is a bit more complicated than that, but this is the general idea of what it does.)</p>
<p>The result is that many blocks simply have their transactions in decreasing feerate order, with transactions that are dependent on each other being placed in order consecutively.</p>
<blockquote>
<p>Do we compute hash based on the set of data after sorting?</p>
</blockquote>
<p>The merkle root is computed with transactions in the order they are found in the block. So once an order is chosen, it is the only correct order for that block. Changing the order will change the merkle root and thus the block hash.</p>
<blockquote>
<p>How does Bitcoin client code decide when to start the nonce + mining process? I understand it has some kind of batch process, so it doesn't start the mining until it can assemble some transactions into a block. But, where's the code to assemble those? Some say miner does whatever they want, but at the end of the day, nobody writes their own client code. There has to be some common code that implements this logic.</p>
</blockquote>
<p>The actual miner and the node (that receives blocks and transactions and builds the block template) are separate software. The node, once it is synced, can build a block template at any time. Depending on how long that node has been online, the template it creates may not be ideal, but it is still usable. There is no requirement that blocks must have more than 1 transaction, so it is perfectly fine for a node to be creating block templates even when it is not aware of any unconfirmed transactions.</p>
<p>So a solo miner might just start their node, wait for it to sync, then start their mining software. There is not any smart determination of when to start mining. Miners generally want to start as soon as possible, as any block reward (starting immediately) is better than no block reward (waiting for transactions).</p>

CC BY-SA 4.0
2021-10-27T20:34:23.040Z
Hi Andrew sorry for digging this out, but I have a question. You said miners are most likely to start mining as soon as possible even if block is empty. But doesn't that mean each time new transaction is added into a block they have to start over? Because hash will change with even slightest change to a block. Im assuming every time someone is broadcasting a transaction to them they have to include it in their block and thus in their proof of work?
gosu94
CC BY-SA 4.0
2021-10-27T22:50:32.137Z
@gosu94 No, there is no requirement that a miner must try to include every new transaction. Miners can very quickly exhaust a nonce range so there isn't really any need to be interrupted every time a new transaction comes in. They'll get those transactions the next time they ask for new work which won't be very long afterwards anyways.
Ava Chow
CC BY-SA 4.0
2021-10-19T01:04:56.580Z
2021-10-19T01:04:56.580Z
Ava Chow
<p>I understand that miners can do whatever they are pleased to do. Either include 0 transaction or 1000 transactions in the block before mining. But I assume majority of the nodes run the same set of code, Bitcoin client. So, I assume there has to be some logic implemented in the code.</p>
<ol>
<li><p>How does miner order transactions if two are unrelated? e.g., A pays C, X pays Y. I assume changing the order in the block will change the hash, so I am curious how Bitcoin code combines them in which order.</p>
</li>
<li><p>How does Bitcoin client code decide when to start the nonce + mining process? I understand it has some kind of batch process, so it doesn't start the mining until it can assemble some transactions into a block. But, where's the code to assemble those? Some say miner does whatever they want, but at the end of the day, nobody writes their own client code. There has to be some common code that implements this logic.</p>
</li>
</ol>

CC BY-SA 4.0
2021-10-19T00:34:50.843Z
> The sequence of blocks is critical (and accommodated as each block is chained to a specific prior block), but the sequence of transactions within a single block is not

But still don't understand what do we mean by order within a block doesn't matter. Do we compute hash based on the set of data after sorting?
ldanfrustdsbflqbsdeedrustdf
<bitcoin-core><transactions><client><transaction-selection>
How does miner order transactions?
ldanfrustdsbflqbsdeedrustdf
# How does miner order transactions?

(Asked by: username_0 on 2021-10-19)

I understand that miners can do whatever they are pleased to do. Either include 0 transaction or 1000 transactions in the block before mining. But I assume majority of the nodes run the same set of code, Bitcoin client. So, I assume there has to be some logic implemented in the code.

1. How does miner order transactions if two are unrelated? e.g., A pays C, X pays Y. I assume changing the order in the block will change the hash, so I am curious how Bitcoin code combines them in which order.
2. How does Bitcoin client code decide when to start the nonce + mining process? I understand it has some kind of batch process, so it doesn't start the mining until it can assemble some transactions into a block. But, where's the code to assemble those? Some say miner does whatever they want, but at the end of the day, nobody writes their own client code. There has to be some common code that implements this logic.

**Tags:** bitcoin-core, transactions, client, transaction-selection

> **Comments:**
> **username_0**: > The sequence of blocks is critical (and accommodated as each block is chained to a specific prior block), but the sequence of transactions within a single block is not  But still don't understand what do we mean by order within a block doesn't matter. Do we compute hash based on the set of data after sorting?  

---

## 1 answers

### Answer by username_1 on 2021-10-19. Score: 5 | Accepted answer

> How does miner order transactions if two are unrelated? e.g., A pays C, X pays Y. I assume changing the order in the block will change the hash, so I am curious how Bitcoin code combines them in which order.

Transactions can be ordered in a block in any way a miner wishes to so long as a transaction which spends an output created by another transaction in that block is placed after its parent. This order does matter for the block hash, and so once the order is decided, it is fixed for that block.

Many miners use Bitcoin Core's block template functionality to build their blocks. This will choose the transactions to include, and an order to include them in. The way Bitcoin Core chooses transactions is to first group related transactions together as packages, then order packages by the feerate paid by the package. Then packages are simply selected in order from highest to lowest until the block weight maximum is reached. (The actual selection is a bit more complicated than that, but this is the general idea of what it does.)

The result is that many blocks simply have their transactions in decreasing feerate order, with transactions that are dependent on each other being placed in order consecutively.

> Do we compute hash based on the set of data after sorting?

The merkle root is computed with transactions in the order they are found in the block. So once an order is chosen, it is the only correct order for that block. Changing the order will change the merkle root and thus the block hash.

> How does Bitcoin client code decide when to start the nonce + mining process? I understand it has some kind of batch process, so it doesn't start the mining until it can assemble some transactions into a block. But, where's the code to assemble those? Some say miner does whatever they want, but at the end of the day, nobody writes their own client code. There has to be some common code that implements this logic.

The actual miner and the node (that receives blocks and transactions and builds the block template) are separate software. The node, once it is synced, can build a block template at any time. Depending on how long that node has been online, the template it creates may not be ideal, but it is still usable. There is no requirement that blocks must have more than 1 transaction, so it is perfectly fine for a node to be creating block templates even when it is not aware of any unconfirmed transactions.

So a solo miner might just start their node, wait for it to sync, then start their mining software. There is not any smart determination of when to start mining. Miners generally want to start as soon as possible, as any block reward (starting immediately) is better than no block reward (waiting for transactions).

> **Comments:**
> **username_2**: Hi Andrew sorry for digging this out, but I have a question. You said miners are most likely to start mining as soon as possible even if block is empty. But doesn't that mean each time new transaction is added into a block they have to start over? Because hash will change with even slightest change to a block. Im assuming every time someone is broadcasting a transaction to them they have to include it in their block and thus in their proof of work?  
> **username_1**: @username_2 No, there is no requirement that a miner must try to include every new transaction. Miners can very quickly exhaust a nonce range so there isn't really any need to be interrupted every time a new transaction comes in. They'll get those transactions the next time they ask for new work which won't be very long afterwards anyways.  

---

