<blockquote>
<p>how does the system associate the balance from several transactions (allocated to different derived public keys) to the same bitcoin &quot;account&quot; or master public key?</p>
</blockquote>
<p>The system must known the XPUB (often the master public key) for it to generate all of the addresses to 'watch'.</p>
<p>While we're on the subject of master public keys and privacy, there are many things that you can do wrong. Sharing your master public key (XPUB) is a bad idea, as the other party will be able to see all of your addresses. I've seen a lot of projects doing this, destroying your privacy basically.</p>
<p>BIP47, still a draft and not implemented, aims to solve this privacy issue and still offers the infinity addresses benefit of HD wallets.</p>
<p>But what you describe, the act of sharing a master public key and letting the CLIENT derive the addresses is bad and isn't the case in most systems. It's a lot more likely that the SERVER derives the addresses and keeps the master public key secret.</p>
<p>So, let's assume the following:</p>
<ol>
<li><p>We have the public key through which all other new public keys (and thus new addresses) can be derived.</p>
</li>
<li><p>We have received one transaction on address 15.</p>
</li>
<li><p>We're bootstrapping a new node and doing an initial block download, and thus have processed 0 blocks.</p>
</li>
<li><p>We lost our previous wallet.dat file, so we don't have a single clue on which addresses we've received any money. We recover our wallet through the public key as described in 1.</p>
<p>At this moment the HD wallet doesn't really know on which addresses it has received any money, but to check if transactions belong to us it has <strong>re</strong>generated a &quot;LOOKAHEAD&quot; of the first 20 addresses. Those 20 <em>potentially used</em> addresses get added to the keypool, all new transactions to these addresses belong to us.</p>
</li>
</ol>
<p>A block gets processed with a transaction to address 15, this falls within our lookahead of 20 so we're able to pick it up. We <strong>re</strong>generate more lookahead addresses once we've found a transaction to one of our addresses.</p>
<p>This lookahead is important, let's assume we took a lookahead of 10, we wouldn't be watching on address 15, only up to address 10. We wouldn't see our transaction. (note: this only applies if you've lost your wallet.dat, and recovered from seed)</p>
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit" rel="nofollow noreferrer">BIP44</a> specifies the &quot;address gap limit&quot; to be 20.</p>
<blockquote>
<p>Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain.</p>
</blockquote>

CC BY-SA 3.0
2017-06-19T09:58:46.150Z
2017-06-19T10:05:00.440Z
2020-06-16T11:10:03.350Z
Penquin
<p>As far as I know (<a href="https://bitcoin.stackexchange.com/questions/718/what-is-a-deterministic-wallet/21200#21200">and as explained here</a>) hierarchical deterministic wallets keep a master key pair (private and public). When using them the public key is newly generated in every transaction. I understood that child keys are generated by elliptic multiplication of parent keys. Benefits associated with HD wallets are claimed to be:</p>

<ul>
<li>Better privacy because new public keys are generated in each
transaction;</li>
<li>It is only needed to store one master private key, as
all the other keys can be derived from it; and</li>
<li>It is possible to
store the master public key on an insecure server and still generate
as many addresses as needed without having to leave the private keys
on that server.</li>
</ul>

<p>While I do more or less understand the theoretical concept, I struggle with the practical implementation of the process, and in particular with how does the system associate the balance from several transactions (allocated to different derived public keys) to the same bitcoin "account" or master public key?</p>

<p>Anyone able to make a "for dummies" clarification?</p>

<wallet><deterministic-wallets>
How do hierarchical deterministic wallets work transaction-wise?
Pisuke Soramame
# How do hierarchical deterministic wallets work transaction-wise?

(Asked by: username_0 on 2017-06-19)

As far as I know ([and as explained here](https://bitcoin.stackexchange.com/questions/718/what-is-a-deterministic-wallet/21200#21200)) hierarchical deterministic wallets keep a master key pair (private and public). When using them the public key is newly generated in every transaction. I understood that child keys are generated by elliptic multiplication of parent keys. Benefits associated with HD wallets are claimed to be:

* Better privacy because new public keys are generated in each
  transaction;
* It is only needed to store one master private key, as
  all the other keys can be derived from it; and
* It is possible to
  store the master public key on an insecure server and still generate
  as many addresses as needed without having to leave the private keys
  on that server.

While I do more or less understand the theoretical concept, I struggle with the practical implementation of the process, and in particular with how does the system associate the balance from several transactions (allocated to different derived public keys) to the same bitcoin "account" or master public key?

Anyone able to make a "for dummies" clarification?

**Tags:** wallet, deterministic-wallets


---

## 1 answers

### Answer by username_1 on 2017-06-19. Score: 3

> how does the system associate the balance from several transactions (allocated to different derived public keys) to the same bitcoin "account" or master public key?

The system must known the XPUB (often the master public key) for it to generate all of the addresses to 'watch'.

While we're on the subject of master public keys and privacy, there are many things that you can do wrong. Sharing your master public key (XPUB) is a bad idea, as the other party will be able to see all of your addresses. I've seen a lot of projects doing this, destroying your privacy basically.

BIP47, still a draft and not implemented, aims to solve this privacy issue and still offers the infinity addresses benefit of HD wallets.

But what you describe, the act of sharing a master public key and letting the CLIENT derive the addresses is bad and isn't the case in most systems. It's a lot more likely that the SERVER derives the addresses and keeps the master public key secret.

So, let's assume the following:

1. We have the public key through which all other new public keys (and thus new addresses) can be derived.
2. We have received one transaction on address 15.
3. We're bootstrapping a new node and doing an initial block download, and thus have processed 0 blocks.
4. We lost our previous wallet.dat file, so we don't have a single clue on which addresses we've received any money. We recover our wallet through the public key as described in 1.

   At this moment the HD wallet doesn't really know on which addresses it has received any money, but to check if transactions belong to us it has **re**generated a "LOOKAHEAD" of the first 20 addresses. Those 20 *potentially used* addresses get added to the keypool, all new transactions to these addresses belong to us.

A block gets processed with a transaction to address 15, this falls within our lookahead of 20 so we're able to pick it up. We **re**generate more lookahead addresses once we've found a transaction to one of our addresses.

This lookahead is important, let's assume we took a lookahead of 10, we wouldn't be watching on address 15, only up to address 10. We wouldn't see our transaction. (note: this only applies if you've lost your wallet.dat, and recovered from seed)

[BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit) specifies the "address gap limit" to be 20.

> Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain.


---

