<p>Yes, you are correct. There is a fixed order, as ensured by the merkle root and the proof of work. Both the blocks and the transactions within each block are strictly ordered.</p>

<p>This order is actually necessary for validation of the transactions within. For example, you could have a transaction Y that depends on the output of transaction X in the <strong>same</strong> block. If Y came before X in the list of transactions in the block, then the block would be an invalid block. </p>

<p>With that said, although the order of transactions within a particular chain snapshot cannot change, the chain itself can change from time time. This happens when there is a fork in the network. Look at this image below:</p>

<p><img src="https://i.sstatic.net/h19zP.png" alt="enter image description here"></p>

<p>Let's say you knew about block A and you thought it was the tip of the best chain. Then all of the sudden the other chain comes out, and block A is replaced by block B. The order of transactions in A might not be the same as the order in B.</p>

<p>It may also interest you to know that to enable Gavin's <code>O(1)</code> block propagation proposal, there is a <a href="https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#canonical-ordering-of-transactions" rel="nofollow noreferrer">canonical ordering for transactions in a block</a>. </p>

CC BY-SA 4.0
2018-06-14T12:55:24.213Z
"If Y came before X in the list of txns in the block, then the block would be an invalid block", how can the user ensure that the miner will place X first and then Y if both were issued very close in time? Both X and Y will be in the unconfirmed pool at the same time, and the miner will order them arbitrarily, right? If the miner sees that the Y->X order is invalid, will it try to order them as X->Y? And what if it was both Y1 and Y2 that depended on X, but the user only wanted Y1 to go through and Y2 to be invalid (insufficient funds), how can user ensure that miner won't put Y2 before Y1?
Joe MB
CC BY-SA 4.0
2018-06-14T14:23:35.050Z
Miner software is smart enough to detect dependencies in transactions and order them appropriately. If two transactions try to use the same output from a transaction, then the miner software will only use one of the two transactions, but how they choose is not enforced. They could choose by first-seen, or they could choose by highest-fee, or any other criteria they want. Same thing applies even when the output that both transactions are trying to spend is in a previous block.
morsecoder
CC BY-SA 3.0
2015-01-25T16:56:51.037Z
2015-01-25T17:07:44.923Z
2015-01-25T17:07:44.923Z
morsecoder
<p>Every block in the block chain contains a list of transactions. This list has a certain order which is basically set by the miner introducing the block. The merkle root in the block header requires that this order is fixed.</p>

<p>Therefore there is a fixed order for all transactions in the blockchain which cannot be modified at a later time (except for the usual temporary forking).</p>

<p>Is that correct?</p>

<transactions><blockchain>
Is there a fixed order for all transactions in the block chain?
Steve
# Is there a fixed order for all transactions in the block chain?

(Asked by: username_0 on 2015-01-25)

Every block in the block chain contains a list of transactions. This list has a certain order which is basically set by the miner introducing the block. The merkle root in the block header requires that this order is fixed.

Therefore there is a fixed order for all transactions in the blockchain which cannot be modified at a later time (except for the usual temporary forking).

Is that correct?

**Tags:** transactions, blockchain


---

## 1 answers

### Answer by username_1 on 2015-01-25. Score: 3

Yes, you are correct. There is a fixed order, as ensured by the merkle root and the proof of work. Both the blocks and the transactions within each block are strictly ordered.

This order is actually necessary for validation of the transactions within. For example, you could have a transaction Y that depends on the output of transaction X in the **same** block. If Y came before X in the list of transactions in the block, then the block would be an invalid block.

With that said, although the order of transactions within a particular chain snapshot cannot change, the chain itself can change from time time. This happens when there is a fork in the network. Look at this image below:

![enter image description here](https://i.sstatic.net/h19zP.png)

Let's say you knew about block A and you thought it was the tip of the best chain. Then all of the sudden the other chain comes out, and block A is replaced by block B. The order of transactions in A might not be the same as the order in B.

It may also interest you to know that to enable Gavin's `O(1)` block propagation proposal, there is a [canonical ordering for transactions in a block](https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#canonical-ordering-of-transactions).

> **Comments:**
> **username_2**: "If Y came before X in the list of txns in the block, then the block would be an invalid block", how can the user ensure that the miner will place X first and then Y if both were issued very close in time? Both X and Y will be in the unconfirmed pool at the same time, and the miner will order them arbitrarily, right? If the miner sees that the Y->X order is invalid, will it try to order them as X->Y? And what if it was both Y1 and Y2 that depended on X, but the user only wanted Y1 to go through and Y2 to be invalid (insufficient funds), how can user ensure that miner won't put Y2 before Y1?  
> **username_1**: Miner software is smart enough to detect dependencies in transactions and order them appropriately. If two transactions try to use the same output from a transaction, then the miner software will only use one of the two transactions, but how they choose is not enforced. They could choose by first-seen, or they could choose by highest-fee, or any other criteria they want. Same thing applies even when the output that both transactions are trying to spend is in a previous block.  

---

