When we're upgrading a wallet, we shouldn't be trying to generate new keys for wallets where private keys are disabled.
Fixes #23610
When private keys are disabled, we should not be trying to generate new
keys during upgradewallet.
Concept ACK
468 | @@ -469,6 +469,12 @@ bool LegacyScriptPubKeyMan::CanGetAddresses(bool internal) const 469 | bool LegacyScriptPubKeyMan::Upgrade(int prev_version, int new_version, bilingual_str& error) 470 | { 471 | LOCK(cs_KeyStore); 472 | + 473 | + if (m_storage.IsWalletFlagSet(WALLET_FLAG_DISABLE_PRIVATE_KEYS)) {
nit: If the user is expecting the wallet upgrade, shouldn't this condition return false and inform the reason in error?
if (m_storage.IsWalletFlagSet(WALLET_FLAG_DISABLE_PRIVATE_KEYS)) {
error = _("Private keys disabled");
return false;
}
No, the wallet is still being upgraded - the version number will change, and in the future (perhaps in CWallet), there may actually be an upgrade. It is fine for an upgrade to do nothing - that is what we do for descriptor wallets.
tACK 34afde0 on Ubuntu 21.10
344 | @@ -345,5 +345,11 @@ def copy_split_hd(): 345 | desc_wallet = self.nodes[0].get_wallet_rpc("desc_upgrade") 346 | self.test_upgradewallet(desc_wallet, previous_version=169900, expected_version=169900) 347 | 348 | + if self.is_bdb_compiled():
can we also test descriptor+disable_private_keys while we're here?
Done
tACK c7376cc8d728f3a7c40f79bd57e7cef685def723 this fixed the issue for me
Code review ACK c7376cc8d728f3a7c40f79bd57e7cef685def723
Milestone
23.0