<p><strong>The SPV uses the <code>Merkle Root</code> in the header to verify transaction information full nodes provide.</strong> As a header refers to the previous block by hash, an SPV wallet can be somewhat sure that it has real blockchain information.</p>

<p>To hear about transactions relevant to it, an SPV requests to get information about any transactions involving a provided set of public keys (some of which actually belong to the SPV, but not all) from a full node. The full node does the look-up, then tells the SPV which blocks have transactions that are relevant for it. Now, the SPV doesn't have all transaction information, and if it only got transation <strong><code>C</code></strong>, it would have no way of knowing that this information is accurate. However, this is where the Merkle root comes into play, as a way to provide minimal information to verify the existence of transactions.</p>

<p><strong>An Example:</strong></p>

<p>Let's say this <strong><code>block X</code></strong> has three transactions <strong><code>A</code></strong>, <strong><code>B</code></strong>, and <strong><code>C</code></strong>; the transaction <strong><code>C</code></strong> being relevant to the SPV.</p>

<p>See the following picture for an overview how the <code>Merkle Root</code> is derived from the three transactions.</p>

<p><img src="https://i.sstatic.net/mrOef.png" alt="enter image description here"></p>

<p>Now, if the full node would just provide <strong><code>C</code></strong>, the SPV would have no idea if the transaction is actually in <strong><code>block X</code></strong>, but by providing also <strong><code>H(A|B)</code></strong>, the SPV can re-derive the <code>Merkle root</code>, allowing it to verify that <strong><code>C</code></strong> is in the block.</p>

<p>To read more about some shortcomings of SPV wallets please refer to <a href="https://bitcoin.stackexchange.com/a/38419/5406">Bitcoin's answer</a>.</p>

CC BY-SA 3.0
2015-07-05T14:01:38.417Z
2015-07-05T14:01:38.417Z
2017-04-13T12:47:36.647Z
Murch
<p>An SPV client uses the headers along with some other data to make sure that the Bitcoin it has been told it has received actually exist for the rest of the network. Absent this assurance, it would be trivial for somebody to simply tell non-validating wallets that they received money when they really didn't. </p>

<p>To prove funds exist without downloading the entire chain, the SPV wallet is supplied with a blocks merkle tree as proof of payment. They can validate that the merkle tree contains a transaction output paying them, that it is from a block with valid proof of work, and that the block header comes from a difficult to produce chain that leads back to the genesis block. Due to the structure of the merkle tree, it can be pruned to contain only transactions which are relevant to the client without changing the hash that was included in a block header, which has significant space and time savings over just sending the whole thing. </p>

<p>The SPV model is quite weak, however. </p>

<ul>
<li><p>Actually finding out which outputs are yours delegates this work to a third party who may not have your privacy at heart, currently in most clients this uses bloom filters which broadcast your interest in wallet information across the network in a very identifying way.</p></li>
<li><p>Not being able to do full validations of blocks means that you could potentially accept payment in a block that the network will not accept because it is invalid in a place you can't validate (spends outputs that don't exist, for example). There is a trust in miners for this security model, and relies on them doing the validation of transactions for the system to be of sufficient security. This is usually supported by waiting for multiple confirmations on transactions, making an assumption about how much a malicious miner will be willing to throw away on an invalid chain in order to dupe SPV clients.</p></li>
<li><p>It has been shown in the 5th of July 2015 forking event that a significant portion of miners do no validation at all of block contents in some situations. In this particular event SPV clients could have seen 6 confirmations (the generally accepted "safe" amount) on transactions which were actually invalited. In this case all SPV wallets and most block explorers (and the wallet services which use their API) were at risk of losses if they accepted money in transactions which were later found to be double spends in the main chaihn.</p></li>
</ul>

CC BY-SA 3.0
2015-07-05T14:57:45.060Z
I'm not sure why people think it's *trivial* for someone to convince SPV clients that a payment was made when it actually wasn't. If a transaction is buried under enough blocks, it's actually *safe enough* to use SPV to prove the payment was made. Unless you're talking about 0-confirmations scenarios?
Luca Matteis
CC BY-SA 3.0
2015-07-05T14:59:43.307Z
The "trivial" comment was meant to *absent* SPV proofs. I've corrected my response to not have the slightly confusing statement in it (wallets without SPV are obviously not SPV wallets).
Claris
CC BY-SA 3.0
2015-07-05T13:59:01.323Z
2015-07-05T15:00:16.763Z
2015-07-05T15:00:16.763Z
Claris
<p>My understanding is that an SPV wallet downloads "headers only". These headers are not enough to get a UTXO set, so it has to rely on another data source when it comes time to move bitcoin. If thats the case, then why does it even need the headers?</p>

<spv>
How does an SPV wallet use the headers that it downloads?
priestc
# How does an SPV wallet use the headers that it downloads?

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

My understanding is that an SPV wallet downloads "headers only". These headers are not enough to get a UTXO set, so it has to rely on another data source when it comes time to move bitcoin. If thats the case, then why does it even need the headers?

**Tags:** spv


---

## 2 answers

### Answer by username_1 on 2015-07-05. Score: 4

**The SPV uses the `Merkle Root` in the header to verify transaction information full nodes provide.** As a header refers to the previous block by hash, an SPV wallet can be somewhat sure that it has real blockchain information.

To hear about transactions relevant to it, an SPV requests to get information about any transactions involving a provided set of public keys (some of which actually belong to the SPV, but not all) from a full node. The full node does the look-up, then tells the SPV which blocks have transactions that are relevant for it. Now, the SPV doesn't have all transaction information, and if it only got transation **`C`**, it would have no way of knowing that this information is accurate. However, this is where the Merkle root comes into play, as a way to provide minimal information to verify the existence of transactions.

**An Example:**

Let's say this **`block X`** has three transactions **`A`**, **`B`**, and **`C`**; the transaction **`C`** being relevant to the SPV.

See the following picture for an overview how the `Merkle Root` is derived from the three transactions.

![enter image description here](https://i.sstatic.net/mrOef.png)

Now, if the full node would just provide **`C`**, the SPV would have no idea if the transaction is actually in **`block X`**, but by providing also **`H(A|B)`**, the SPV can re-derive the `Merkle root`, allowing it to verify that **`C`** is in the block.

To read more about some shortcomings of SPV wallets please refer to [Bitcoin's answer](https://bitcoin.stackexchange.com/a/38419/5406).


---

### Answer by username_2 on 2015-07-05. Score: 1

An SPV client uses the headers along with some other data to make sure that the Bitcoin it has been told it has received actually exist for the rest of the network. Absent this assurance, it would be trivial for somebody to simply tell non-validating wallets that they received money when they really didn't.

To prove funds exist without downloading the entire chain, the SPV wallet is supplied with a blocks merkle tree as proof of payment. They can validate that the merkle tree contains a transaction output paying them, that it is from a block with valid proof of work, and that the block header comes from a difficult to produce chain that leads back to the genesis block. Due to the structure of the merkle tree, it can be pruned to contain only transactions which are relevant to the client without changing the hash that was included in a block header, which has significant space and time savings over just sending the whole thing.

The SPV model is quite weak, however.

* Actually finding out which outputs are yours delegates this work to a third party who may not have your privacy at heart, currently in most clients this uses bloom filters which broadcast your interest in wallet information across the network in a very identifying way.
* Not being able to do full validations of blocks means that you could potentially accept payment in a block that the network will not accept because it is invalid in a place you can't validate (spends outputs that don't exist, for example). There is a trust in miners for this security model, and relies on them doing the validation of transactions for the system to be of sufficient security. This is usually supported by waiting for multiple confirmations on transactions, making an assumption about how much a malicious miner will be willing to throw away on an invalid chain in order to dupe SPV clients.
* It has been shown in the 5th of July 2015 forking event that a significant portion of miners do no validation at all of block contents in some situations. In this particular event SPV clients could have seen 6 confirmations (the generally accepted "safe" amount) on transactions which were actually invalited. In this case all SPV wallets and most block explorers (and the wallet services which use their API) were at risk of losses if they accepted money in transactions which were later found to be double spends in the main chaihn.

> **Comments:**
> **username_3**: I'm not sure why people think it's *trivial* for someone to convince SPV clients that a payment was made when it actually wasn't. If a transaction is buried under enough blocks, it's actually *safe enough* to use SPV to prove the payment was made. Unless you're talking about 0-confirmations scenarios?  
> **username_2**: The "trivial" comment was meant to *absent* SPV proofs. I've corrected my response to not have the slightly confusing statement in it (wallets without SPV are obviously not SPV wallets).  

---

