<p>If it helps <a href="https://gist.github.com/TOMOAKI12345/7e0aa1c6b8ace4a70ca6" rel="noreferrer">https://gist.github.com/TOMOAKI12345/7e0aa1c6b8ace4a70ca6</a> </p>

<p><a href="https://github.com/voisine/breadwallet" rel="noreferrer">Breadwallet</a> source code is really good source to learn about the network protocol of SPV wallet.</p>

CC BY-SA 4.0
2020-09-17T09:27:14.477Z
Breadwallet source is not available any more.
Andrija
CC BY-SA 3.0
2015-09-01T01:13:14.353Z
2015-09-01T01:13:14.353Z
Tomoaki Sato
<p>Just found something in bitcoinj sourcecode:</p>

<pre><code>/**
 * The "getheaders" command is structurally identical to "getblocks", but has different meaning. On receiving this
 * message a Bitcoin node returns matching blocks up to the limit, but without the bodies. It is useful as an
 * optimization: when your wallet does not contain any keys created before a particular time, you don't have to download
 * the bodies for those blocks because you know there are no relevant transactions.
 */
</code></pre>

CC BY-SA 3.0
2013-05-20T06:53:08.373Z
2013-05-20T06:53:08.373Z
Jonas Schnelli
<p>In addition to above answers, You could refer to this diagram if it helps from this <a href="https://gist.github.com/TOMOAKI12345/7e0aa1c6b8ace4a70ca6" rel="nofollow noreferrer">link</a>.</p>

<p><a href="https://i.sstatic.net/LlOKv.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/LlOKv.png" alt="enter image description here"></a></p>

CC BY-SA 3.0
2018-02-15T16:12:12.443Z
2018-02-15T16:12:12.443Z
Suraj Jain
<p>I think SPV is only meant to verify transactions, not calculate a balance or list of all transactions to a certain address.</p>

CC BY-SA 3.0
2013-05-20T06:48:31.383Z
But how does Multibit (a SPV thin-client) check for incomming payments so fast?
Jonas Schnelli
CC BY-SA 3.0
2013-05-20T20:53:47.460Z
@Jonas, Multibit uses bloom filters, that why it can check for incomming payments that fast.
rdymac
CC BY-SA 3.0
2013-06-19T09:36:02.127Z
I downvoted. Verifying transaction is exactly the thing SPV does not do: it only verifies the block chain, not the transactions in it.
Pieter Wuille
CC BY-SA 3.0
2016-01-25T00:02:33.470Z
SPV clients can calculate balances and can list transactions to certain addresses by requesting filtered blocks. SPV clients also verify transaction validity by verifying the signatures; what SPV does not verify is inclusion of outputs in the utxo, so double spending is possible.
dionyziz
CC BY-SA 3.0
2016-09-05T17:17:31.367Z
@dionyziz SPV clients cannot verify signatures, as they don't have the UTXO entries to know what to verify against.
Pieter Wuille
CC BY-SA 3.0
2013-05-19T20:57:30.413Z
2013-05-19T20:57:30.413Z
RentFree
<p>You are right that SPV as described in the Bitcoin paper does not explain how to discover payments to yourself, without downloading full blocks. My guess is that Satoshi either planned to develop this later, or that he assumed you'd just be told about payments to yourself (pay-to-IP, as existed next to pay-to-pubkeyhash as is used now).</p>

<p>Practical implementations of SPV nodes today however use a protocol extension called bloom filters, described in <a href="https://en.bitcoin.it/wiki/BIP_0037">BIP 37</a>. They use <code>getheaders</code> to fetch block information prior to their wallet's birth timestamp, and request <em>filtered blocks</em> afterwards. To do so, they submit a bloom filter that describes the addresses and transactions they are interested in to the peer. The peer then only includes the relevant transactions in blocks it submits, together with their Merkle paths to prove that these transactions were indeed part of said block.</p>

CC BY-SA 3.0
2013-06-19T09:44:23.557Z
2013-06-19T09:44:23.557Z
Pieter Wuille
<p>I try to understand a SPV implementation.</p>

<p>I read the wiki pages on <a href="https://en.bitcoin.it/wiki/Protocol_specification" rel="noreferrer">Protocol Specification</a> and <a href="https://en.bitcoin.it/wiki/Thin_Client_Security" rel="noreferrer">Thin Client Security</a> as well as the <a href="http://bitcoin.org/bitcoin.pdf" rel="noreferrer">white-paper's</a> chapter 8 .</p>

<p>What I don't understand:<br>
Assume user <code>A</code> has Bitcoin address <code>X</code>.<br>
User <code>A</code> can do <code>getheaders</code> and load all block headers and then have all block hashes and timestamps.</p>

<p>So: how does a SPV client then find possible transactions to the user's Bitcoin address <code>X</code> without loading all blocks (and all transactions)?</p>

<spv><bip37-bloom-filter>
How do SPV (simple payment verification) wallets learn about incoming transactions?
Jonas Schnelli
# How do SPV (simple payment verification) wallets learn about incoming transactions?

(Asked by: username_0 on 2013-05-19)

I try to understand a SPV implementation.

I read the wiki pages on [Protocol Specification](https://en.bitcoin.it/wiki/Protocol_specification) and [Thin Client Security](https://en.bitcoin.it/wiki/Thin_Client_Security) as well as the [white-paper's](http://bitcoin.org/bitcoin.pdf) chapter 8 .

What I don't understand:  
Assume user `A` has Bitcoin address `X`.  
User `A` can do `getheaders` and load all block headers and then have all block hashes and timestamps.

So: how does a SPV client then find possible transactions to the user's Bitcoin address `X` without loading all blocks (and all transactions)?

**Tags:** spv, bip37-bloom-filter


---

## 5 answers

### Answer by username_6 on 2013-06-19. Score: 21 | Accepted answer

You are right that SPV as described in the Bitcoin paper does not explain how to discover payments to yourself, without downloading full blocks. My guess is that Satoshi either planned to develop this later, or that he assumed you'd just be told about payments to yourself (pay-to-IP, as existed next to pay-to-pubkeyhash as is used now).

Practical implementations of SPV nodes today however use a protocol extension called bloom filters, described in [BIP 37](https://en.bitcoin.it/wiki/BIP_0037). They use `getheaders` to fetch block information prior to their wallet's birth timestamp, and request *filtered blocks* afterwards. To do so, they submit a bloom filter that describes the addresses and transactions they are interested in to the peer. The peer then only includes the relevant transactions in blocks it submits, together with their Merkle paths to prove that these transactions were indeed part of said block.


---

### Answer by username_1 on 2015-09-01. Score: 6

If it helps <https://gist.github.com/TOMOAKI12345/7e0aa1c6b8ace4a70ca6>

[Breadwallet](https://github.com/voisine/breadwallet) source code is really good source to learn about the network protocol of SPV wallet.

> **Comments:**
> **username_2**: Breadwallet source is not available any more.  

---

### Answer by username_0 on 2013-05-20. Score: 3

Just found something in bitcoinj sourcecode:
/**
 * The "getheaders" command is structurally identical to "getblocks", but has different meaning. On receiving this
 * message a Bitcoin node returns matching blocks up to the limit, but without the bodies. It is useful as an
 * optimization: when your wallet does not contain any keys created before a particular time, you don't have to download
 * the bodies for those blocks because you know there are no relevant transactions.
 */


---

### Answer by username_3 on 2018-02-15. Score: 1

In addition to above answers, You could refer to this diagram if it helps from this [link](https://gist.github.com/TOMOAKI12345/7e0aa1c6b8ace4a70ca6).

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


---

### Answer by username_4 on 2013-05-19. Score: -4

I think SPV is only meant to verify transactions, not calculate a balance or list of all transactions to a certain address.

> **Comments:**
> **username_0**: But how does Multibit (a SPV thin-client) check for incomming payments so fast?  
> **username_5**: @Jonas, Multibit uses bloom filters, that why it can check for incomming payments that fast.  
> **username_6**: I downvoted. Verifying transaction is exactly the thing SPV does not do: it only verifies the block chain, not the transactions in it.  
> **username_7**: SPV clients can calculate balances and can list transactions to certain addresses by requesting filtered blocks. SPV clients also verify transaction validity by verifying the signatures; what SPV does not verify is inclusion of outputs in the utxo, so double spending is possible.  
> **username_6**: @username_7 SPV clients cannot verify signatures, as they don't have the UTXO entries to know what to verify against.  

---

