<p>Block fetching requests are also filtered, so the client requests every single block they missed out on seeing since the last time they were last online, sequentially. The client downloads all block headers from genesis up to the current head using <code>getheaders</code>, sets a filter on their peer with <code>filterload</code>, and then downloads filtered blocks with <code>getdata</code> until they are in sync with the network. <code>filteradd</code> may be used in deterministic wallets to extend the filter to include more keys as used ones are discovered in their scan. When they are in sync, they will only receive new inventory that matches the filter. </p>

CC BY-SA 3.0
2015-04-07T20:36:13.703Z
So if a filter is set, then `getdata` will return partially filled blocks, with only transactions satisfying the filter inside them?
morsecoder
CC BY-SA 3.0
2015-04-07T21:11:56.027Z
Yes. [BIP37](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki) is a good place to start.
Claris
CC BY-SA 3.0
2015-04-07T18:45:48.020Z
2015-04-07T18:45:48.020Z
Claris
<p>SPV nodes rely on their peers to send them transaction data that is relevant to them. When an SPV node sets up a bloom filter with one of their full node peers, doesn't that only tell the full node which transactions to send the SPV node <em>from now on</em>? </p>

<p>How do SPV nodes catch up after being offline? Which p2p calls can they use to get their transaction info from their peers?</p>

<transactions><spv><bip37-bloom-filter>
How do SPV get their transactions after being offline?
morsecoder
# How do SPV get their transactions after being offline?

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

SPV nodes rely on their peers to send them transaction data that is relevant to them. When an SPV node sets up a bloom filter with one of their full node peers, doesn't that only tell the full node which transactions to send the SPV node *from now on*?

How do SPV nodes catch up after being offline? Which p2p calls can they use to get their transaction info from their peers?

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


---

## 1 answers

### Answer by username_1 on 2015-04-07. Score: 5 | Accepted answer

Block fetching requests are also filtered, so the client requests every single block they missed out on seeing since the last time they were last online, sequentially. The client downloads all block headers from genesis up to the current head using `getheaders`, sets a filter on their peer with `filterload`, and then downloads filtered blocks with `getdata` until they are in sync with the network. `filteradd` may be used in deterministic wallets to extend the filter to include more keys as used ones are discovered in their scan. When they are in sync, they will only receive new inventory that matches the filter.

> **Comments:**
> **username_0**: So if a filter is set, then `getdata` will return partially filled blocks, with only transactions satisfying the filter inside them?  
> **username_1**: Yes. [BIP37](https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki) is a good place to start.  

---

