# Saving Disk Space
> *"A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes, until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in."*\
> — **Satoshi Nakamoto**, *Bitcoin Whitepaper*
***
#### **Why Disk Space Isn’t a Problem**
Over the years, some have misunderstood the impact of Bitcoin’s **growing ledger size**.
Critics claimed that as the blockchain expands to **gigabytes or terabytes**, it would become too heavy for everyday users to download and synchronize.
However, this concern stems from **a misinterpretation** of how Bitcoin was designed to work.
**Satoshi’s original design** allows each user to verify transactions **without storing the entire blockchain**, thanks to the **efficiency of Merkle trees** and **block headers**.
Bitcoin was **always intended for massive scalability** — processing millions of transactions in unbounded blocks — with validation handled by **enterprise-grade nodes** connected through high-capacity networks.
***
#### **How Transactions Are Managed**
Each time a transaction is made on the **BSV network**, the **locking script** of a previous **unspent transaction output (UTXO)** is consumed as an input.\
The new transaction then:
* Creates **fresh UTXOs** for the recipients, and
* Generates **change outputs** that return leftover value to the sender.
The **difference between total inputs and outputs** forms the **transaction fee**, which is collected by the node that includes the transaction in a block.
***
#### **Pruning Old Data**
Once all UTXOs from a transaction are spent, **there’s no need for nodes to retain that transaction’s full data**.
This enables nodes to **prune** their databases, keeping only:
* **Unspent outputs (current UTXO set)**
* **Block headers**
* **Merkle trees** linking those UTXOs to prior proofs of work
Through these structures, **all tokens can be accounted for — past and present**.
A **Merkle tree** that has had some transactions removed or added is called a **Working Blockchain**.
It contains only the **active, relevant transactions** for a given application or audit, while still being **anchored to the proof-of-work** of the main chain.
Archival nodes may choose to **store full transaction histories**, but this is **voluntary or service-based** — driven by economic incentives such as **paid data retrieval or compliance verification**.
***
#### **How Light Wallets Stay Efficient**
For a casual user, there’s **no need to maintain the full ledger or complete UTXO set**.
A wallet simply needs to store:
* **Block headers**
* **TXIDs** and **TX indexes**
* **Merkle proofs** for its own UTXOs
Since each **block header is only 80 bytes**, and around **144 blocks** are added per day, that’s just **4.2 MB of data per year**— smaller than a single digital photo.
When verification is required, the wallet can **query miners or nodes** for the **Merkle path values** corresponding to its UTXOs and check them against the **Merkle root** in the block header.
Even for extremely large datasets, verification remains light.\
For example, a Merkle tree with **2¹⁰⁰⁰ transactions** would still require only **\~32 KB** of hash data to verify a transaction.
| **Number of Transactions** | **Approx. Block Size** | **Path Size (Hashes)** | **Path Size (Bytes)** |
| -------------------------- | ---------------------- | ---------------------- | --------------------- |
| 16 | 4 KB | 4 | 128 B |
| 512 | 128 KB | 9 | 288 B |
| 2,048 | 512 KB | 11 | 352 B |
| 65,535 | 16 MB | 16 | 512 B |
***
#### **Why Merkle Trees Enable Scalability**
As discussed earlier in the course, the **Merkle tree structure** is inherently **scalable and efficient**.
When new transactions are added, only the **right-hand branches** and the **Merkle root** are recalculated — while **existing subtrees remain intact**.
This allows:
* **Parallel processing** across nodes
* **Faster validation** of large transaction sets
* **Reduced computational overhead**
If Bitcoin had been built on data structures like **linked lists**, verifying transactions would be far slower, and **simplified payment verification (SPV)** would not work — because there’d be no compact proof linking a transaction to its block.
***
#### **Key Takeaway**
Bitcoin’s architecture — particularly its **Merkle tree** and **block header** design — allows it to **scale infinitely** without sacrificing decentralization or efficiency.\
Nodes can prune old data safely, while light clients can verify transactions with only a few kilobytes of information.
Through this elegant system, Bitcoin could achieve **global-scale data integrity** while keeping **disk space and bandwidth requirements minimal**.
---
# 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/saving-disk-space.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.