# Data Integrity of the Block
To understand **data integrity** in Bitcoin, let’s explore what happens when someone tries to **modify a block** after it has already been mined and accepted.
Below are the **raw fields** from the **block header of block #550204**, first introduced in the course, '[Merkle trees and the block header](https://bsvblockchain.360learning.com/course/play/68e4d36956898420e69230d7)'.
#### **Attempting to Alter a Mined Block**
Now, imagine trying to **add another transaction** to this block **after** a valid proof-of-work solution has already been found and **broadcast to the network**.
For instance, suppose someone attempts to insert a **double-spend transaction**—one that tries to reuse coins already spent elsewhere.
To simulate this:
1. The **TXID** (Transaction ID) of the new transaction is converted to **little-endian** format.
2. It is **double-hashed** to produce the **right-hand branch value**.
3. The original **Merkle root** (also in little-endian) serves as the **left-hand branch value**.
4. Both are **concatenated and double-hashed** to form a **new Merkle root**.
This modified Merkle root is then inserted into the **Merkle root field** of the block header, creating a **new 80-byte header string**.
#### **Result: The Hash No Longer Fits the Difficulty Target**
After this modification, the **new block header** is passed through **double SHA-256** to produce a new block hash.
However, the resulting hash doesn’t even come **close** to falling below the **difficulty target** — meaning it **fails the proof-of-work requirement**.
To make this altered block valid, miners would have to:
* **Increment the nonce** repeatedly, testing new hashes.
* Continue until a **valid proof-of-work solution** is found again — a process that would require enormous computational effort.
***
#### **Why Changing a Block Breaks the Chain**
This exercise illustrates a core principle of Bitcoin’s security:\
Each block’s **hash** is tightly bound to its **header fields**, including the **Merkle root** and **previous block hash**.
If any field changes—even a single transaction—the resulting hash becomes **completely different**.
That means:
* The **proof-of-work** for the altered block **no longer holds**.
* The **subsequent block** (which depends on the old hash) also becomes invalid.
* To “fix” the chain, the attacker would have to **re-mine every block** from the altered one onward.
***
#### **The Cost of a Double-Spend Attack**
To successfully introduce a **new version of a block** with altered transactions (like redirecting tokens to oneself), an attacker must:
1. **Recompute the proof-of-work** for the changed block.
2. Then **solve the next hash puzzle** faster than honest nodes.
3. Finally, **extend their version of the chain** to make it the **longest**—and convince the network to adopt it.
If the change goes back **multiple blocks**, the attacker must **redo the proof-of-work for all subsequent blocks**, and still **catch up** to the legitimate chain tip.
In practice, this makes reversing transactions that are **deeply buried** (e.g., 6+ confirmations) **computationally impossible**.
#### **The Role of the Merkle Tree in Data Integrity**
The **Merkle tree** is what makes such tampering detectable instantly.\
By recalculating only the hashes along a transaction’s branch, a node can **quickly verify** whether a block’s transaction set produces the **same Merkle root**.
This efficiency lets nodes decide, within milliseconds, whether to:
* **Accept** the broadcast block and start mining on top of it, or
* **Continue** their own proof-of-work if the block appears invalid.
In the **BSV network**, where miners compute **trillions of hashes per second**, every moment counts.
Fast and accurate verification gives each node a **competitive advantage** in solving the next block’s puzzle.
***
#### **Key Takeaway**
Once a block has been mined and accepted, **any modification to its data** changes its **Merkle root**, invalidates its **proof-of-work**, and **breaks the chain’s continuity**.
Re-mining the chain to “fix” it is computationally infeasible — making Bitcoin’s ledger **immutable by design**.
The **Merkle tree** is the mechanism that guarantees this **data integrity**, linking every transaction and every block in a chain of **cryptographic certainty**.
---
# 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-verifying-proof-of-work/data-integrity-of-the-block.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.