# Transaction Merkle Trees in Action

{% file src="/files/Yv3EVBfUyxxFBcjqASqd" %}

*(The video above demonstrates the process of the serialised strings of raw data from a bitcoin transaction being converted through two applications of the SHA256 function to a 32-byte value for the leaf nodes of a Merkle tree.)*

This section demonstrates how **raw transaction data** is transformed into **TXIDs** and then into a **Merkle Tree structure**.

Through this process, Bitcoin ensures that every transaction is **uniquely identifiable** and **verifiable** across the network.

***

### From Raw Data to Leaf Nodes

Each **leaf node** in a Merkle Tree begins as a **serialized string** of raw transaction data.

This string is passed through the **SHA-256 hash function twice**, producing a **32-byte value** that becomes the **Transaction ID (TXID)**.

When experimenting with hashing tools, it’s important to note:

* Many online hash calculators interpret input as **ASCII characters**, not **hexadecimal**.
* To generate the correct TXID, your implementation must either:
  * Convert the input from hexadecimal to binary or decimal, or
  * Specify that the input is **hexadecimal**.
* After hashing, the output is displayed in **Little Endian format** (byte order reversed).\
  This can cause a mismatch between your locally generated hash and the one shown in a **block explorer**, which displays it in **Big Endian**.

***

### Why Double Hashing Is Used

At first glance, performing **two rounds of SHA-256 hashing** might seem unnecessary.

However, this **double hashing (HASH256)** serves a practical purpose.

By creating an initial hash of the transaction data:

* **Miners** and **other network participants** can share intermediate results more efficiently.
* This allows a **division of labour** during mining, where specialized nodes can process partial data without exposing the entire raw transaction.
* It also provides an additional layer of protection against data manipulation.

***

### Understanding TXID Representation

In hexadecimal notation, every **byte** of data is represented by **two characters**.\
So a 32-byte TXID will appear as **64 hexadecimal characters**.

When the byte order is reversed (from Little Endian to Big Endian), the system rearranges each **pair of hex characters**, moving them from the back to the front in sequence.

This step ensures compatibility with the standard display order used by most blockchain explorers.

***

### Building the Merkle Tree

Once multiple TXIDs are generated, they form the **leaf nodes** of a Merkle Tree.\
Pairs of TXIDs are **concatenated and hashed twice** to produce the **interior node values**.

This continues until a single **Merkle Root** is created — representing all underlying transactions in the block.

For example:

1. **Four TXIDs** are hashed in pairs to form two interior nodes.
2. These interior nodes are concatenated and hashed again to produce the **Merkle Root**.
3. The Merkle Root is stored in **Little Endian format** within the **block header**, linking the transaction set to the blockchain.

***

### Appending New Transactions

When a **new transaction** is added, its TXID becomes an additional leaf node.\
The Merkle Tree is recalculated, generating a **new Merkle Root**.

This process follows a predictable pattern:

* The **existing left-hand structure** of the tree remains unchanged.
* The **new TXID** extends the right-hand side.
* Once the number of leaves exceeds a power of two (e.g., 2⁴ → 2⁵), a new **layer** is created to maintain balance.

Over time, this structure scales dynamically — ensuring that each transaction addition preserves both **integrity** and **efficiency**.

***

### Key Takeaway

**Transaction Merkle Trees in Action** reveal how BSV maintains a **verifiable, scalable, and tamper-resistant record** of transactions.

Through **double hashing**, **endian encoding**, and **incremental tree updates**, the system ensures:

* Each transaction has a **unique TXID** derived from raw data.
* The **Merkle Root** securely summarizes all transactions in a block.
* The tree structure **updates efficiently** as new transactions are appended.
* Verification can occur **without revealing full transaction data** — the cornerstone of scalability and privacy in BSV.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://hub.bsvblockchain.org/higher-learning/bsv-academy/bitcoin-primitives-merkle-trees/merkle-trees-in-bitcoin-and-bsv/transaction-merkle-trees-in-action.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.