bitcoin-cli loadwallet

[ascqrwasc33]

I have this strange problem and would like to know if any of you too has or had encountered the same:
When I fire in console A:

Code:

bitcoin-cli loadwallet walletname

The bitcoind (Daemon console) running on console B says
 [walletname] Wallet completed loading in            2368ms

BUT
The command which I fired on console A does not return back immediately. It makes me wait for easily around 8 to 9 minutes before giving me my prompt back. I need to run
the

Code:

walletpassphrase

command as well after that. But it takes a lot of time and makes me wait. Pressing Ctrl+C renders the loadwallet attempt useless and I have to stop the daemon and restart it and again fire the loadwallet command. The wallet has only 8-10 BTC addresses still it returns back the CLI prompt very slowly. OI am using the latest btc daemon and tools. Any advise how to solve this?

[achow101]

How long is it between the "Wallet completed loading" message and a message that says "setKeyPool.size() ="? Although the completion line is logged near the end of the loading process, there is still a bit more that it does afterwards. In particular, if your wallet is not fully synced, it will do a scan of the blocks that have occurred since the wallet was last loaded, and depending on how long that is, it can take a while.

Having to use walletpassphrase after loading a wallet is expected if your wallet is encrypted. I'm not sure what you're expecting with that.

[ascqrwasc33]

Thank you for your response.

Having to use walletpassphrase after loading a wallet is expected if your wallet is encrypted. I'm not sure what you're expecting with that.

Well, nothing. I know it is expected. I am saying the delay because of loadwallet is a hindrance since I want to run the walletpassphrase command.

How long is it between the "Wallet completed loading" message and a message that says "setKeyPool.size() ="?

I ran a benchmark again as per your enquiry.

The  setKeyPool.size() message appears exactly around the timestamp when I get my prompt back. So when the system is rebooted, it takes around 8 to 9 minutes. This time I did a bitcoin-cli stop and re-ran the daemon and the attempt to load the wallet took 4.5 minutes. That's when the prompt was returned back and the setKeyPool.size() message was echoed back.

[achow101]

Between the "loading completed" and "setKeyPool.size" lines, do you also see log lines like "Rescanning last X blocks (from block Y)...", "Still rescanning." "Scanning current mempool transactions" and "Recsan completed in"? It's probably spending those several minutes doing the rescan.

How long the rescan takes depends on how far behind the wallet is from the node's tip. If you are unloading the wallet but letting the node remain operational, then you're going to run into this a lot.

[ascqrwasc33]

Do you mean the delay can only be minimized / eliminated if the node is always current and fully synced? If I stop bitcoin daemon and come back after a week, the wallet loading will take more than expected?

[achow101]

Do you mean the delay can only be minimized / eliminated if the node is always current and fully synced? If I stop bitcoin daemon and come back after a week, the wallet loading will take more than expected?

No, the wallet just needs to be in sync with the node.

[ascqrwasc33]

I had kept the system off for some time to conduct a test.
I just ran

Code:

bitcoin-cli getblockcount 

and I am 147 blocks behind.

I tried to load my wallet and I got the prompt back within a second. The command just ran as it should, no delays.
Not sure whether it is because earlier my node was lagging behind a lot.

Code:

2024-05-12T00:18:00Z [walletnamehere] Wallet completed loading in            1083ms
2024-05-12T00:18:01Z [walletnamehere] setKeyPool.size() = 8000
2024-05-12T00:18:01Z [walletnamehere] mapWallet.size() = 0
2024-05-12T00:18:01Z [walletnamehere] m_address_book.size() = 13

There were no 'rescanning' messages seen, atleast not now.

Pardon my ignorance but what does 'the wallet just needs to be in sync with the node' mean?
Isn't that the same as having the blocks current, because the wallet actually fetches info from my node.

Thanks.

[achow101]

Pardon my ignorance but what does 'the wallet just needs to be in sync with the node' mean?
Isn't that the same as having the blocks current, because the wallet actually fetches info from my node.

The wallet maintains its own state separate from the blockchain and other node related things. This only happens if that particular wallet is loaded. You may have Bitcoin Core running without any wallet being loaded - Bitcoin Core is still functioning as a node as it downloads and validates all blocks and transactions. The same would happen if just that specific wallet wasn't loaded but others were - those other wallets would be updated, but the unloaded ones are not. So when you load the wallet again, Bitcoin Core will not have looked for any transactions that pertain to the wallet. It does that on loading, which is why you see it take a while.

[seoincorporation]

Can you give us a hardware description, maybe you are running this on a raspberry pi, which would explain why the delay, or maybe it's an old machine with low resources.

If you are running in linux you can concatenate the commands;

Code:

bitcoin-cli loadwallet walletname; bitcoin-cli walletpassphrase "my pass phrase"; 

Or even use the sleep command between both commands:

Code:

bitcoin-cli loadwallet walletname; sleep 2600; bitcoin-cli walletpassphrase "my pass phrase"; 

It will not make it go faster, but you can leave it running and come back later once all is loaded.

[ascqrwasc33]

Hi, yes it is indeed an old system, but enough to act as a full node. Not mining though lol
Aware of ; and sleep.
Thanks
achow101 and seoincorporation for the clarifications.
I tried to give you both sMerits but I don't have any

[NotATether]

Hi, yes it is indeed an old system, but enough to act as a full node. Not mining though lol

An old system? How old is the hard disk inside the computer if you don't mind me asking? And is it an HDD or SSD?

The older a hard disk gets, the more bad sectors it forms which generally slow down read operations in any program. It could make reads take several seconds to complete for instance. You can't even kill a program in linux with SIGKILL while it's blocked by an I/O read or write.

I'm not sure if SSDs have this sort of problem but I don't think there is one in your computer.