<p>Yes, <code>importprivkey</code> will stop being supported entirely whenever support for legacy wallets is removed, <a href="https://github.com/bitcoin/bitcoin/issues/20160" rel="noreferrer">probably</a> in version 28.0. Old wallets will of course be covertible to the new format.</p>
<p>However, it is perfectly possible to import things into new wallets that involve private keys, using the <code>importdescriptors</code> RPC, which has different arguments and different semantics, but almost certainly covers your use case. See the documentation for <code>importprivkey</code>, which mentions:</p>
<blockquote>
<p>Note: This command is only compatible with legacy wallets. Use &quot;importdescriptors&quot; with &quot;combo(X)&quot; for descriptor wallets.</p>
</blockquote>
<p>The reason for not supporting <code>importprivkey</code> in legacy wallets is that its behavior is hard to reason about, and intentionally not supported anymore for descriptor wallets:</p>
<ul>
<li><code>importprivkey</code> is effectively a &quot;here is a key, figure out what I want to do with it&quot;. It will cause certain (but not all) single-key addresses related to that key to become part of the wallet, but it will also do things like making a multisig script the wallet knew about go from watch-only to fully supported if it now has all its keys.</li>
<li>With <code>importdescriptor</code> (and the philosophy behind descriptor wallets in general), you have to be explicit about what/how you want to use the key.</li>
</ul>

CC BY-SA 4.0
2024-01-16T14:43:27.617Z
2024-01-16T15:27:27.580Z
2024-01-16T15:27:27.580Z
Pieter Wuille
<p>I'm running bitcoin core 26.0 on debian 12.</p>
<pre><code>$ /usr/local/bin/bitcoin-26.0/bin/bitcoin-cli importprivkey &quot;5-rest-of-priv-key&quot;
error code: -4
error message:
Only legacy wallets are supported by this command
</code></pre>
<p>Okay so I can have bitcoin core 26.0 run with an old wallet.dat file, and the priv-key import will then work fine, so that's nice. But, this works <strong>only</strong> with <strong>old</strong> wallet.dat files.</p>
<p>Are there any plans, or is there a widely shared disposition among developers, to stop future releases of bitcoin core from being able to import priv-keys to <em>old</em> wallet.dat files -- as is already the case with <em>newly created</em> wallet.dat files -- and thus to deprecate the &quot;importprivkey&quot; call completely?</p>

<bitcoin-core><bitcoin-core-development><wallet.dat><private-key-import>
Gradual deprecation of importprivkey call?
Lilacrail
# Gradual deprecation of importprivkey call?

(Asked by: username_0 on 2024-01-16)

I'm running bitcoin core 26.0 on debian 12.
$ /usr/local/bin/bitcoin-26.0/bin/bitcoin-cli importprivkey "5-rest-of-priv-key"
error code: -4
error message:
Only legacy wallets are supported by this command

Okay so I can have bitcoin core 26.0 run with an old wallet.dat file, and the priv-key import will then work fine, so that's nice. But, this works only with old wallet.dat files.
Are there any plans, or is there a widely shared disposition among developers, to stop future releases of bitcoin core from being able to import priv-keys to old wallet.dat files -- as is already the case with newly created wallet.dat files -- and thus to deprecate the "importprivkey" call completely?

**Tags:** bitcoin-core, bitcoin-core-development, wallet.dat, private-key-import


---

## 1 answers

### Answer by username_1 on 2024-01-16. Score: 7

Yes, `importprivkey` will stop being supported entirely whenever support for legacy wallets is removed, [probably](https://github.com/bitcoin/bitcoin/issues/20160) in version 28.0. Old wallets will of course be covertible to the new format.

However, it is perfectly possible to import things into new wallets that involve private keys, using the `importdescriptors` RPC, which has different arguments and different semantics, but almost certainly covers your use case. See the documentation for `importprivkey`, which mentions:

> Note: This command is only compatible with legacy wallets. Use "importdescriptors" with "combo(X)" for descriptor wallets.

The reason for not supporting `importprivkey` in legacy wallets is that its behavior is hard to reason about, and intentionally not supported anymore for descriptor wallets:

* `importprivkey` is effectively a "here is a key, figure out what I want to do with it". It will cause certain (but not all) single-key addresses related to that key to become part of the wallet, but it will also do things like making a multisig script the wallet knew about go from watch-only to fully supported if it now has all its keys.
* With `importdescriptor` (and the philosophy behind descriptor wallets in general), you have to be explicit about what/how you want to use the key.


---

