<p>That is correct, you can only do this with non-hardened derivation. Only non-hardened derivation can use the master public key to derive all of the public keys. With hardened derivation, you must have the master private key in order to derive anything.</p>

CC BY-SA 4.0
2018-07-30T17:19:23.223Z
So doesn't that mean the auditor use case described by bip 32 is invalid? There is no way I could have a true auditor
David says Reinstate Monica
CC BY-SA 4.0
2018-07-30T17:52:20.713Z
@DavidGrinberg as the quote in the OP says you would share account level extended public keys (xpubs) not the root extended public key. The account level could be hardened so that the auditor only sees the accounts you give him access to. So for example you could have accounts at m/k'/j/i where k is the hardened account level, j is 0 for external address and 1 for internal change addresses and i is the address index. You would share the xpub for m/k' with the auditor. For example: if you only share the xpubs for accounts 1-3 he won't be able to traverse the tree for account 4.
Abdussamad
CC BY-SA 4.0
2018-07-30T19:58:22.500Z
@Abdussamad doesn't this break the point of an auditor though? I could make a new xpub account and not tell the auditor. They would be none the wiser
David says Reinstate Monica
CC BY-SA 4.0
2018-07-30T20:33:43.133Z
Even with non-hardened derivation you could make a new account and not tell the auditor. With fiat, you can make new banking accounts and not tell the auditors. There's always room for lying by omission in an audit, and this does not change that. At least it is easier for an auditor to perform audits when BIP 32 is used as many of the addresses can be derived instead of relying on someone to provide all of them and possibly omit some.
Ava Chow
CC BY-SA 4.0
2018-07-30T16:28:02.930Z
2018-07-30T16:28:02.930Z
Ava Chow
<p>BIP 32 allows you to to implement the <a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Audits_Nm" rel="nofollow noreferrer">auditor use case</a>:</p>

<blockquote>
  <p>Audits: N(m/*) 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.</p>
</blockquote>

<p>If I want all my bitcoin transactions to be fully audited, then I would need to give my auditor my master node details. However I obviously don't want to give him my master node secret key since he would be able to steal my money. Thus I could only give the auditor my master public key and the chain code. With that he will be able to derive all public keys and see all my transactions.</p>

<p>But that means that my <em>entire</em> tree can only use non-harded BIP-32. Is that correct or am I missing something?</p>

<private-key><public-key><bip32-hd-wallets><deterministic-wallets><audits>
Is auditing a BIP32 tree only possible if it is non-hardened?
David says Reinstate Monica
# Is auditing a BIP32 tree only possible if it is non-hardened?

(Asked by: username_0 on 2018-07-27)

BIP 32 allows you to to implement the [auditor use case](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Audits_Nm):

> Audits: N(m/\*) 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.

If I want all my bitcoin transactions to be fully audited, then I would need to give my auditor my master node details. However I obviously don't want to give him my master node secret key since he would be able to steal my money. Thus I could only give the auditor my master public key and the chain code. With that he will be able to derive all public keys and see all my transactions.

But that means that my *entire* tree can only use non-harded BIP-32. Is that correct or am I missing something?

**Tags:** private-key, public-key, bip32-hd-wallets, deterministic-wallets, audits


---

## 1 answers

### Answer by username_1 on 2018-07-30. Score: 2

That is correct, you can only do this with non-hardened derivation. Only non-hardened derivation can use the master public key to derive all of the public keys. With hardened derivation, you must have the master private key in order to derive anything.

> **Comments:**
> **username_0**: So doesn't that mean the auditor use case described by bip 32 is invalid? There is no way I could have a true auditor  
> **username_2**: @DavidGrinberg as the quote in the OP says you would share account level extended public keys (xpubs) not the root extended public key. The account level could be hardened so that the auditor only sees the accounts you give him access to. So for example you could have accounts at m/k'/j/i where k is the hardened account level, j is 0 for external address and 1 for internal change addresses and i is the address index. You would share the xpub for m/k' with the auditor. For example: if you only share the xpubs for accounts 1-3 he won't be able to traverse the tree for account 4.  
> **username_0**: @username_2 doesn't this break the point of an auditor though? I could make a new xpub account and not tell the auditor. They would be none the wiser  
> **username_1**: Even with non-hardened derivation you could make a new account and not tell the auditor. With fiat, you can make new banking accounts and not tell the auditors. There's always room for lying by omission in an audit, and this does not change that. At least it is easier for an auditor to perform audits when BIP 32 is used as many of the addresses can be derived instead of relying on someone to provide all of them and possibly omit some.  

---

