<blockquote>
  <p>Why one would need <em>extended</em> public keys for the auditing a bip32 wallet?</p>
</blockquote>

<p>You don't <em>need</em> them. You could also just make a list of all of the addresses that have a balance, and send that to your auditor.</p>

<p>Auditing a Bitcoin wallet is not a very good example of what this is capable of. Here are some other uses of BIP32:</p>

<ul>
<li>You could have a script on a server with an extended public key generate addresses for people to donate to, without having that same server be able to spend money sent to those addresses. Without BIP32, you'd have to make a long list of addresses, put them on your server, and replenish them whenever they ran out.</li>
<li>You could have an e-commerce app generate addresses like the above, and detect payments to those addresses without, again, having the ability to spend them.</li>
</ul>

<blockquote>
  <p>Wouldn't the (non-extended) elliptic curve encryption's public keys work too?</p>
</blockquote>

<p>No. You also need the chain code to calculate the subkeys. Collectively, these two things make up an extended public key.</p>

<blockquote>
  <p>Furthermore, if I understand the spec properly, sharing an extended public key isn't really safe since knowing a descending non-hardened private key would then expose all the keys descending from this first extended public key.</p>
</blockquote>

<p>It's... debatably safe. I don't think there's a real-word situation where someone would compromise one of your non-hardened private keys without having access to all of them.</p>

CC BY-SA 3.0
2014-11-30T19:56:54.680Z
In my mind, you didn't need to calculate subkeys since you give all the (used) public keys (N(M/*)). But in this case you would need to store all the public keys.
idkwptc
CC BY-SA 3.0
2014-11-30T20:00:05.570Z
`you didn't need to calculate subkeys since you give all the public keys (N(M/*))` I don't understand. Could you clarify?
Nick ODell
CC BY-SA 3.0
2014-11-30T20:03:21.407Z
Well (I'm no expert at all so I may say something totally wong) each transaction related to the wallet use a public key (point on ec) so storing the used points should be enough to perform an audit without sharing the chaincodes, isn't it ?
idkwptc
CC BY-SA 3.0
2014-11-30T20:05:07.507Z
@idkwptc You could store the used points or the addresses. Either would work, for an audit.
Nick ODell
CC BY-SA 3.0
2014-11-30T20:08:13.587Z
Ok, I wanted to be sure I understood the principle. Sharing the extended public keys as advised in the specs looked "debatably safe" to me given the way the keys were generated. Thank you for your time ! :)
idkwptc
CC BY-SA 3.0
2014-11-30T20:18:24.263Z
Btw, I said something (partially) wrong earlier. The way the key are generated, the owner of the wallet "knows" the used key by the indexes (M/x/y/z) of the keys so no need to store explicitly the points/addresses sharing *non-extended* public keys...a great secure way to use hd wallets !
idkwptc
CC BY-SA 3.0
2016-12-12T07:45:36.177Z
I have downloaded bitcoin core, do you happen to know where can I find the bip32 extended key for this wallet ?
coding_idiot
CC BY-SA 3.0
2014-11-30T19:44:53.040Z
2015-08-02T01:19:04.140Z
2015-08-02T01:19:04.140Z
Nick ODell
<p>(I am reading the bip32 for an altcoin development.)</p>

<p>In the bip32 specification, it is written that listing all incoming and outgoing payments of a hierarchical deterministic wallet would required the <strong><em>extended</em></strong> public keys.</p>

<blockquote>
  <p>In case an auditor needs full access to the list of incoming and outgoing payments, one can share all account public <strong><em>extended</em></strong> keys. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.</p>
</blockquote>

<p>Wouldn't the (non-extended) elliptic curve encryption's public keys work too ?</p>

<p>Furthermore, if I understand the spec properly, sharing an extended public key isn't really safe since knowing a descending non-hardened private key would then expose all the keys descending from this first extended public key...and sharing a non-extended public key would avoid the problem. </p>

<bip32-hd-wallets><wallet-security>
Why one would need *extended* public keys for auditing a bip32 wallet?
idkwptc
# Why one would need *extended* public keys for auditing a bip32 wallet?

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

(I am reading the bip32 for an altcoin development.)

In the bip32 specification, it is written that listing all incoming and outgoing payments of a hierarchical deterministic wallet would required the ***extended*** public keys.

> In case an auditor needs full access to the list of incoming and outgoing payments, one can share all account public ***extended*** keys. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.

Wouldn't the (non-extended) elliptic curve encryption's public keys work too ?

Furthermore, if I understand the spec properly, sharing an extended public key isn't really safe since knowing a descending non-hardened private key would then expose all the keys descending from this first extended public key...and sharing a non-extended public key would avoid the problem.

**Tags:** bip32-hd-wallets, wallet-security


---

## 1 answers

### Answer by username_1 on 2014-11-30. Score: 1 | Accepted answer

> Why one would need *extended* public keys for the auditing a bip32 wallet?

You don't *need* them. You could also just make a list of all of the addresses that have a balance, and send that to your auditor.

Auditing a Bitcoin wallet is not a very good example of what this is capable of. Here are some other uses of BIP32:

* You could have a script on a server with an extended public key generate addresses for people to donate to, without having that same server be able to spend money sent to those addresses. Without BIP32, you'd have to make a long list of addresses, put them on your server, and replenish them whenever they ran out.
* You could have an e-commerce app generate addresses like the above, and detect payments to those addresses without, again, having the ability to spend them.

> Wouldn't the (non-extended) elliptic curve encryption's public keys work too?

No. You also need the chain code to calculate the subkeys. Collectively, these two things make up an extended public key.

> Furthermore, if I understand the spec properly, sharing an extended public key isn't really safe since knowing a descending non-hardened private key would then expose all the keys descending from this first extended public key.

It's... debatably safe. I don't think there's a real-word situation where someone would compromise one of your non-hardened private keys without having access to all of them.

> **Comments:**
> **username_0**: In my mind, you didn't need to calculate subkeys since you give all the (used) public keys (N(M/*)). But in this case you would need to store all the public keys.  
> **username_1**: `you didn't need to calculate subkeys since you give all the public keys (N(M/*))` I don't understand. Could you clarify?  
> **username_0**: Well (I'm no expert at all so I may say something totally wong) each transaction related to the wallet use a public key (point on ec) so storing the used points should be enough to perform an audit without sharing the chaincodes, isn't it ?  
> **username_1**: @username_0 You could store the used points or the addresses. Either would work, for an audit.  
> **username_0**: Ok, I wanted to be sure I understood the principle. Sharing the extended public keys as advised in the specs looked "debatably safe" to me given the way the keys were generated. Thank you for your time ! :)  
> **username_0**: Btw, I said something (partially) wrong earlier. The way the key are generated, the owner of the wallet "knows" the used key by the indexes (M/x/y/z) of the keys so no need to store explicitly the points/addresses sharing *non-extended* public keys...a great secure way to use hd wallets !  
> **username_2**: I have downloaded bitcoin core, do you happen to know where can I find the bip32 extended key for this wallet ?  

---

