# Proof-of-Work in Action
In this example, we examine **Block 550204**, which contains **two transactions**.\
We’ll walk through how these transactions are hashed, combined into a **Merkle Root**, and finally used in the **block header** for the **Proof-of-work** process.
#### **Step 1: From Transactions to TXIDs**
Each transaction’s **raw data** is first hashed twice using **SHA-256** (Ps. `HASH256` is SHA-256 applied twice in succession), producing its **Transaction ID (TXID)**.
These TXIDs form the **leaf nodes** of a two-layer **Merkle Tree**. The TXIDs are then concatenated and double-hashed again to produce the **Merkle Root**.
> ⚙️ **Endian note:**\
> Hash outputs are displayed in **Little Endian** format.\
> When comparing to **Block Explorer** data (usually shown in **Big Endian**), you must **reverse the byte order** of each hexadecimal pair to match.
>
> Similarly, if building a Merkle Tree from block explorer TXIDs, reverse each to **Little Endian** before concatenating them.
#### **Step 2: The Merkle Root and Block Header**
The resulting **Merkle Root** is inserted into the **block header** as one of its six data fields.
To create the full **80-byte header string**, several conversions are required:
* Convert all **decimal fields** to **hexadecimal**.
* Reverse each field’s **byte order** (from Big to Little Endian).
* **Concatenate** all elements in the correct sequence.
Although confusing for humans, **Little Endian encoding** is **faster for hardware** to process — a small optimization that matters when the system scales to **millions of transactions per second**.
#### **Step 3: Evaluating the Hash Puzzle**
To check if a block solves the **Proof-of-work puzzle**, the **HASH256** of the entire block header must be **lower than the difficulty target** calculated from the **nBits** field.
This target is derived from the formula:
> **Target = coefficient × 2⁸ × (index − 3)**
For Block 550204,
* nBits = `0x180202F3`
* Index = `0x18` → 24 (decimal)
* Coefficient = `0x0202F3` → 131,827 (decimal)
Plugging these in:
> **Target = 131,827 × 2⁸ × (24−3) = 4.93 × 10⁵⁵**
#### **Step 4: First Attempt – Invalid Hash**
In the miner’s first attempt:
* The **double-hashed block header** produced a value of approximately `1.96 × 10⁷⁶`.
* The **target** was only `4.93 × 10⁵⁵`.
Since the result is **much higher than the target**, the attempt **fails**.
To try again, the **nonce** is incremented by 1 — producing a new header string that differs by only **one hexadecimal character**.
#### **Step 5: Second Attempt – Valid Hash**
After incrementing the nonce:
* The new **block hash** becomes `3.28 × 10⁵⁵`,
* Which is **lower than the target** (`4.93 × 10⁵⁵`).
This means the miner has found a **valid Proof-of-work solution**.
The block can now be **submitted to the network** for verification by other nodes.
#### **Key Takeaway**
The **Proof-of-work** process involves continuously changing a small part of the block header (the **nonce**) and hashing it until the resulting value is **below the target threshold**.
This demonstrates Bitcoin’s **computational fairness** — only through genuine work can a miner earn the right to add a new block to the chain.
---
# 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-and-the-block-header/proof-of-work-in-action.md?ask=
```
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.