<p>Trying to enumerate all private keys using Bitcoin Core's wallet is extremely inefficient. Furthermore, any address that you generate in Bitcoin Core will inherently come from a HD seed because Bitcoin Core is a HD wallet and uses a HD seed. You also aren't going to get any information for a HD address that is not part of your wallet.</p>

<blockquote>
  <p>However, I am not sure <code>getaddressinfo</code> is sentitive to this <code>keypoolinfo</code> parameter or is just checking the addresses so far generated (the ones that can be obtained via <code>bitcoin-cli listreceivedbyaddress 0 true</code>).</p>
</blockquote>

<p>It is "sensitive" to the keypool. When you add keys to the keypool, they are actually generated and saved to the wallet file along with some metadata. <code>getaddressinfo</code> looks up whatever metadata is available regardless of the associated key being in the keypool or not.</p>

<blockquote>
  <p>I could test this with a second node but my other node might be using another seed to generate new addresses.</p>
</blockquote>

<p>Unless you have explicitly set a specific seed, then it most definitely is. Otherwise that would be a security vulnerability and anyone could steal anyone else's coins if they all used the same seed.</p>

<blockquote>
  <p>Even though I used sethdseed, I see a different xpriv when dumping the wallet.</p>
</blockquote>

<p>You need to provide the seed of your first wallet. Otherwise it will generate a new random seed and use that.</p>

CC BY-SA 4.0
2019-11-28T16:30:30.483Z
Thanks for the quick answer, good to know `getaddressinfo` is 'sensitive to `keypoolrefill`. Is there any way to read the information contained inside `wallet.dat` (or `fee_estimates.dat` for that matter?)


Regarding the last the last topic, yes, I know every new wallet will have a random new seed by default, it just seemed that I was not 'overriding' this new seed with the `sethdseed` command that I used to import
Pedro
CC BY-SA 4.0
2019-11-28T03:17:31.037Z
2019-11-28T03:17:31.037Z
Ava Chow
<p>I want to know if an address is spendable by an HD seed and for that purpose I am using the following command:</p>

<pre><code>&gt; bitcoin-cli getaddressinfo 3LFc64RRd96ejjYvm14KaogBF9fmeNmePW | jq '.solvable'
false
</code></pre>

<p>However as mentioned <a href="https://bitcoin.stackexchange.com/questions/60545/is-it-possible-to-check-if-an-address-was-generated-from-an-hd-public-key">here</a> and <a href="https://bitcoin.stackexchange.com/questions/48493/can-you-detect-that-the-addresses-generated-by-an-hd-wallet-came-from-a-single-w">here</a> it's impossible to know with 100% certainty that an HD seed can't spend from a certain address as one would need to generate infinite addresses. To counterbalance that I discovered a command that increases the 'search space':</p>

<pre><code>&gt; bitcoin-cli keypoolrefill 1000
</code></pre>

<p>However, I am not sure <code>getaddressinfo</code> is sentitive to this <code>keypoolinfo</code> parameter or is just checking the addresses so far generated (the ones that can be obtained via <code>bitcoin-cli listreceivedbyaddress 0 true</code>). I could test this with a second node but my other node might be using another seed to generate new addresses. Even though I used <code>sethdseed</code>, I see a different <code>xpriv</code> when dumping the wallet.</p>

<bitcoin-core><json-rpc><bip32-hd-wallets><seed><spending>
Knowing if a public address is spendable by an HD seed?
Pedro
# Knowing if a public address is spendable by an HD seed?

(Asked by: username_0 on 2019-11-28)

I want to know if an address is spendable by an HD seed and for that purpose I am using the following command:
> bitcoin-cli getaddressinfo 3LFc64RRd96ejjYvm14KaogBF9fmeNmePW | jq '.solvable'
false

However as mentioned here and here it's impossible to know with 100% certainty that an HD seed can't spend from a certain address as one would need to generate infinite addresses. To counterbalance that I discovered a command that increases the 'search space':
> bitcoin-cli keypoolrefill 1000

However, I am not sure getaddressinfo is sentitive to this keypoolinfo parameter or is just checking the addresses so far generated (the ones that can be obtained via bitcoin-cli listreceivedbyaddress 0 true). I could test this with a second node but my other node might be using another seed to generate new addresses. Even though I used sethdseed, I see a different xpriv when dumping the wallet.

**Tags:** bitcoin-core, json-rpc, bip32-hd-wallets, seed, spending


---

## 1 answers

### Answer by username_1 on 2019-11-28. Score: 2 | Accepted answer

Trying to enumerate all private keys using Bitcoin Core's wallet is extremely inefficient. Furthermore, any address that you generate in Bitcoin Core will inherently come from a HD seed because Bitcoin Core is a HD wallet and uses a HD seed. You also aren't going to get any information for a HD address that is not part of your wallet.

> However, I am not sure `getaddressinfo` is sentitive to this `keypoolinfo` parameter or is just checking the addresses so far generated (the ones that can be obtained via `bitcoin-cli listreceivedbyaddress 0 true`).

It is "sensitive" to the keypool. When you add keys to the keypool, they are actually generated and saved to the wallet file along with some metadata. `getaddressinfo` looks up whatever metadata is available regardless of the associated key being in the keypool or not.

> I could test this with a second node but my other node might be using another seed to generate new addresses.

Unless you have explicitly set a specific seed, then it most definitely is. Otherwise that would be a security vulnerability and anyone could steal anyone else's coins if they all used the same seed.

> Even though I used sethdseed, I see a different xpriv when dumping the wallet.

You need to provide the seed of your first wallet. Otherwise it will generate a new random seed and use that.

> **Comments:**
> **username_0**: Thanks for the quick answer, good to know `getaddressinfo` is 'sensitive to `keypoolrefill`. Is there any way to read the information contained inside `wallet.dat` (or `fee_estimates.dat` for that matter?)   Regarding the last the last topic, yes, I know every new wallet will have a random new seed by default, it just seemed that I was not 'overriding' this new seed with the `sethdseed` command that I used to import  

---

