<p>The reason you pre-generate some forward keys is to avoid the situation you describe, if you only looked ahead one you risk missing a transaction in the current block (the order of the transactions in the block are unrelated to the order of your keys). </p>

<p>The term "gap limit" refers to a parameter of non bloomfilter SPV clients which do look ups by querying an address based index on a remote peer. The gap limit is the end stop of the current wallet state, when the scanning wallet sees 10 empty address results in a row they decide that's probably the last used address in the wallet and give up generating further. If there wasn't a gap limit in place they would search unused addresses until the end of time (or 2**128, which ever came first). </p>

CC BY-SA 3.0
2015-04-06T14:25:27.127Z
2015-04-06T14:25:27.127Z
Claris
<p>I'm working on <a href="https://github.com/keeshux/WaSPV" rel="noreferrer">my SPV library</a> and I still have a hard time figuring how to approach the BIP32 + Bloom filters combination. Here's how I currently sync an existing HD wallet (after fast catch-up):</p>

<ol>
<li>Generate a number of watched look-ahead addresses (say 10).</li>
<li>Load a Bloom filter with all used addresses plus look-ahead (N used + 10 look-ahead).</li>
<li>Download filtered blocks with <code>getdata</code>.</li>
<li>Mark watched addresses as used if they're found in any block transaction.</li>
<li>Ensure that the last watched address wasn't used in a transaction.</li>
<li>If so, generate new look-ahead addresses, reload the Bloom filter and download last block again to rematch it. By using a new receive address for each transaction we may have missed other transactions in the same block.</li>
<li>Otherwise, go back to 4 and download new blocks.</li>
</ol>

<p>Now this sounds quirky and overcomplicated to me. Several discussions on the web talk about "scanning keys" when coming to wallet sync and I don't really understand if they assume a full node or a lightweight SPV node, because I have no idea of how to "scan keys" without a global UTXO database. Also the gap limit only seems to make sense for a full node.</p>

<p>I'm stuck, thanks.</p>

<synchronization><bip32-hd-wallets><spv><utxo><bip37-bloom-filter>
BIP32 wallet sync with Bloom filters
keeshux
# BIP32 wallet sync with Bloom filters

(Asked by: username_0 on 2014-08-30)

I'm working on [my SPV library](https://github.com/username_0/WaSPV) and I still have a hard time figuring how to approach the BIP32 + Bloom filters combination. Here's how I currently sync an existing HD wallet (after fast catch-up):

1. Generate a number of watched look-ahead addresses (say 10).
2. Load a Bloom filter with all used addresses plus look-ahead (N used + 10 look-ahead).
3. Download filtered blocks with `getdata`.
4. Mark watched addresses as used if they're found in any block transaction.
5. Ensure that the last watched address wasn't used in a transaction.
6. If so, generate new look-ahead addresses, reload the Bloom filter and download last block again to rematch it. By using a new receive address for each transaction we may have missed other transactions in the same block.
7. Otherwise, go back to 4 and download new blocks.

Now this sounds quirky and overcomplicated to me. Several discussions on the web talk about "scanning keys" when coming to wallet sync and I don't really understand if they assume a full node or a lightweight SPV node, because I have no idea of how to "scan keys" without a global UTXO database. Also the gap limit only seems to make sense for a full node.

I'm stuck, thanks.

**Tags:** synchronization, bip32-hd-wallets, spv, utxo, bip37-bloom-filter


---

## 1 answers

### Answer by username_1 on 2015-04-06. Score: 2

The reason you pre-generate some forward keys is to avoid the situation you describe, if you only looked ahead one you risk missing a transaction in the current block (the order of the transactions in the block are unrelated to the order of your keys).

The term "gap limit" refers to a parameter of non bloomfilter SPV clients which do look ups by querying an address based index on a remote peer. The gap limit is the end stop of the current wallet state, when the scanning wallet sees 10 empty address results in a row they decide that's probably the last used address in the wallet and give up generating further. If there wasn't a gap limit in place they would search unused addresses until the end of time (or 2\*\*128, which ever came first).


---

