<h2>Transaction order in the block</h2>

<p>Currently, there are only two requirements for the order of transactions: </p>

<ol>
<li>The <a href="https://bitcoin.stackexchange.com/q/4571/5406">coinbase transaction</a> is always first.  </li>
<li>Intra block dependencies must preceed, i.e. if <code>Transaction A</code> and <code>Transaction B</code> are both in the same block, and <code>Transaction B</code> spends outputs of <code>Transaction A</code>, <code>A</code> must be listed before <code>B</code>.</li>
</ol>

<p>It is likely that in the future a correct order for transaction will be introduced, as this will allow proving the absence of a transaction in a block with logarithmic effort, and will allow more efficient block data propagation through <a href="https://bitcoin.stackexchange.com/q/30648/5406">IBLT</a>. Right now, transactions are propagated in the network before confirmation, and then again as the content of a block. With a deterministic transaction order and IBLT set reconciliation, each transaction would only have to be received once instead of twice.</p>

<h2>Building the Merkle Tree</h2>

<p><img src="https://i.sstatic.net/gsi1h.png" alt="Schematic how to create Merkle Tree"></p>

<p>The transactions are inserted into the Merkle Tree in the same order they are listed in the block. If a block only contains the Coinbase Transaction, the Coinbase's transaction ID is used as the Merkle Root.<br>
Otherwise, a binary tree is created from the transactions by pairing transaction hashes on the first level, then pairing resulting hashes on each next level until only one hash results, which is then used as the Merkle Root. If there is an odd number of hashes to be paired, the last hash is paired with itself.</p>

<h2>Further Reading</h2>

<p>The <a href="https://bitcoin.org/en/developer-reference#merkle-trees" rel="nofollow noreferrer">Developer Reference</a> has additional details. The image is from the Developer Reference as well, and hence licensed MIT.<br>
Antonopoulos covers <a href="http://chimera.labs.oreilly.com/books/1234000001802/ch07.html#merkle_trees" rel="nofollow noreferrer">Merkle trees in detail in his book</a>, also providing examples of how it is used to prove transaction presence in blocks.</p>

CC BY-SA 3.0
2015-05-04T16:06:40.860Z
Also of relevance: https://bitcoin.org/en/developer-reference#merkle-trees
Christopher Gurnee
CC BY-SA 3.0
2015-05-08T09:23:05.767Z
@ChristopherGurnee: Thanks that had the information that I was looking for. :)
Murch
CC BY-SA 3.0
2015-05-08T12:40:22.217Z
Excellent updated answer IMO!
Christopher Gurnee
CC BY-SA 4.0
2020-06-22T18:13:39.727Z
Does this relate to the so-called CTOR vs TTOR comparison?
Chris Chen
CC BY-SA 3.0
2015-05-04T10:57:07.793Z
2015-07-16T21:57:24.863Z
2017-04-13T12:47:32.940Z
Murch
<p>For constructing the merkle tree txids are paired and hashed. <a href="https://bitcoin.org/en/developer-guide#transaction-data" rel="nofollow">¹</a> <br/>
<strong>But how are these txids paired? Does it happen chronologically or is there a certain pattern of pairing?</strong></p>

<transactions><merkle-tree><transaction-id>
Pairing pattern of txids in merkle tree
Aliakbar Ahmadi
# Pairing pattern of txids in merkle tree

(Asked by: username_0 on 2015-05-04)

For constructing the merkle tree txids are paired and hashed. [¹](https://bitcoin.org/en/developer-guide#transaction-data)   
**But how are these txids paired? Does it happen chronologically or is there a certain pattern of pairing?**

**Tags:** transactions, merkle-tree, transaction-id


---

## 1 answers

### Answer by username_1 on 2015-05-04. Score: 4 | Accepted answer

## Transaction order in the block

Currently, there are only two requirements for the order of transactions:

1. The [coinbase transaction](https://bitcoin.stackexchange.com/q/4571/5406) is always first.
2. Intra block dependencies must preceed, i.e. if `Transaction A` and `Transaction B` are both in the same block, and `Transaction B` spends outputs of `Transaction A`, `A` must be listed before `B`.

It is likely that in the future a correct order for transaction will be introduced, as this will allow proving the absence of a transaction in a block with logarithmic effort, and will allow more efficient block data propagation through [IBLT](https://bitcoin.stackexchange.com/q/30648/5406). Right now, transactions are propagated in the network before confirmation, and then again as the content of a block. With a deterministic transaction order and IBLT set reconciliation, each transaction would only have to be received once instead of twice.

## Building the Merkle Tree

![Schematic how to create Merkle Tree](https://i.sstatic.net/gsi1h.png)

The transactions are inserted into the Merkle Tree in the same order they are listed in the block. If a block only contains the Coinbase Transaction, the Coinbase's transaction ID is used as the Merkle Root.  
Otherwise, a binary tree is created from the transactions by pairing transaction hashes on the first level, then pairing resulting hashes on each next level until only one hash results, which is then used as the Merkle Root. If there is an odd number of hashes to be paired, the last hash is paired with itself.

## Further Reading

The [Developer Reference](https://bitcoin.org/en/developer-reference#merkle-trees) has additional details. The image is from the Developer Reference as well, and hence licensed MIT.  
Antonopoulos covers [Merkle trees in detail in his book](http://chimera.labs.oreilly.com/books/1234000001802/ch07.html#merkle_trees), also providing examples of how it is used to prove transaction presence in blocks.

> **Comments:**
> **username_2**: Also of relevance: https://bitcoin.org/en/developer-reference#merkle-trees  
> **username_1**: @username_2: Thanks that had the information that I was looking for. :)  
> **username_2**: Excellent updated answer IMO!  
> **username_3**: Does this relate to the so-called CTOR vs TTOR comparison?  

---

