<p>The <a href="https://github.com/bitcoin/bitcoin/blob/0.6.2/src/main.cpp#L1643" rel="nofollow">first transaction has to be the miner's reward</a>.  The other transactions can't be miner rewards.  Transactions have to appear after any transactions upon which they depend.  Other than that the order is up to the miner.  Changing the order of the transactions is one of the things a miner can do to change the block hash once he has tried all possible values of nonce.</p>

<p>I don't know what you're referring to with your "regenerating the block for later retrieval".  As far as I know blocks aren't regenerated.  They're created by a miner, passed around the network, and stored on disk.  There's no need to regenerate them.</p>

CC BY-SA 3.0
2016-03-28T22:57:09.117Z
How does one specify those dependencies between transactions? How does a miner know about dependencies?
Mitar
CC BY-SA 3.0
2012-05-30T09:01:49.590Z
Transactions can depend on other transactions. For example, when you spend change from a previous output that was not yet confirmed. In this case, both transactions can be mined into the same blocks, but the dependent one has to be last.
Pieter Wuille
CC BY-SA 3.0
2012-05-30T10:02:22.660Z
@PieterWuille Thanks.  I updated my answer accordingly.
Chris Moore
CC BY-SA 3.0
2012-05-30T18:03:26.727Z
Thanks Chris for your answer, this is helpful.  To clarify regenerating the block, I'm thinking about storing the blocks in a relational database.  Instead of storing the merkle tree in the database (giant blob of text) I'm storing the order of the transactions with a position column on the transactions table.  Then I can regenerate the merkle tree and wouldn't need to duplicate all the tx hashes.  But I'm still debating...just keeping the merkle tree in the blocks table would negate the need to regenerate it each time and store tx position.
Brian Armstrong
CC BY-SA 3.0
2012-05-30T18:33:46.407Z
OK, so you will need to have a column that stores the order of the transactions.  When you 'regenerate' the block from your database and pass it to a peer, the peer will want to be able to hash it and make sure the hash is less than the required target, which it won't be if you have reordered the transactions.
Chris Moore
CC BY-SA 3.0
2012-05-30T23:13:02.680Z
@BrianArmstrong: I wouldn't recommend trying to convert the block into any other format and expecting to be able to perfectly regenerate the block. Unless you're using a protocol that's specifically designed to be distinguished, there's always a risk that some unusual thing in the block will break your attempt to regenerate it. My advice would be to either store the block as is or do not attempt to regenerate it.
David Schwartz
CC BY-SA 3.0
2012-05-30T07:25:47.277Z
2012-05-30T10:02:00.927Z
2012-05-30T10:02:00.927Z
Chris Moore
<p>It seems to be random or up to the miner from what I can tell.</p>

<p>But to store blocks, one must keep the order of the transactions (in some position column, etc) because regenerating the block for later retrieval requires putting the transactions back in the same order.  Is this correct?</p>

CC BY-SA 3.0
2012-05-30T07:54:49.157Z
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.
Stephen Gornick
<transactions><blockchain><block><merkle-tree>
What order do transactions appear in a block? Is it up to the miner?
Brian Armstrong
# What order do transactions appear in a block? Is it up to the miner?

(Asked by: username_0 on 2012-05-30)

It seems to be random or up to the miner from what I can tell.

But to store blocks, one must keep the order of the transactions (in some position column, etc) because regenerating the block for later retrieval requires putting the transactions back in the same order. Is this correct?

**Tags:** transactions, blockchain, block, merkle-tree

> **Comments:**
> **username_1**: 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.  

---

## 1 answers

### Answer by username_2 on 2012-05-30. Score: 5

The [first transaction has to be the miner's reward](https://github.com/bitcoin/bitcoin/blob/0.6.2/src/main.cpp#L1643). The other transactions can't be miner rewards. Transactions have to appear after any transactions upon which they depend. Other than that the order is up to the miner. Changing the order of the transactions is one of the things a miner can do to change the block hash once he has tried all possible values of nonce.

I don't know what you're referring to with your "regenerating the block for later retrieval". As far as I know blocks aren't regenerated. They're created by a miner, passed around the network, and stored on disk. There's no need to regenerate them.

> **Comments:**
> **username_4**: Transactions can depend on other transactions. For example, when you spend change from a previous output that was not yet confirmed. In this case, both transactions can be mined into the same blocks, but the dependent one has to be last.  
> **username_2**: @username_4 Thanks.  I updated my answer accordingly.  
> **username_0**: Thanks username_2 for your answer, this is helpful.  To clarify regenerating the block, I'm thinking about storing the blocks in a relational database.  Instead of storing the merkle tree in the database (giant blob of text) I'm storing the order of the transactions with a position column on the transactions table.  Then I can regenerate the merkle tree and wouldn't need to duplicate all the tx hashes.  But I'm still debating...just keeping the merkle tree in the blocks table would negate the need to regenerate it each time and store tx position.  
> **username_2**: OK, so you will need to have a column that stores the order of the transactions.  When you 'regenerate' the block from your database and pass it to a peer, the peer will want to be able to hash it and make sure the hash is less than the required target, which it won't be if you have reordered the transactions.  
> **username_5**: @username_0: I wouldn't recommend trying to convert the block into any other format and expecting to be able to perfectly regenerate the block. Unless you're using a protocol that's specifically designed to be distinguished, there's always a risk that some unusual thing in the block will break your attempt to regenerate it. My advice would be to either store the block as is or do not attempt to regenerate it.  
> **username_3**: How does one specify those dependencies between transactions? How does a miner know about dependencies?  

---

