Memory usage
When BTCRecover starts, it counts every password it is about to try, recording duplicates so no password is tested twice and so it can display an accurate ETA. This duplicate-checking phase can consume a large amount of RAM depending on the size of your search space.
If BTCRecover hangs after displaying Counting passwords ... or crashes outright, run it again with --no-dupchecks:
python3 btcrecover.py --wallet ./wallet.dat --tokenlist tokens.txt --no-dupchecks
--no-dupchecks levels
You can pass --no-dupchecks multiple times to progressively disable more duplicate-checking logic:
| Times used | Effect |
|---|
| 1 | Disables the most memory-intensive duplicate check |
| 2 | Disables checks that rarely use much memory relative to their benefit |
| 3 | Disables checks that use very little memory — almost never useful |
| 4 | Disables checks that use no memory at all — for debugging only |
--no-eta
You can skip the counting phase entirely with --no-eta. This is not recommended for normal use, but can be necessary when the password space is too large to count. If you do use it, also add --no-dupchecks:
python3 btcrecover.py --wallet ./wallet.dat --tokenlist tokens.txt --no-eta --no-dupchecks
MultiBit and Electrum wallets
For MultiBit Classic and Electrum wallets, duplicate checking can actually decrease CPU efficiency while always increasing memory usage. A single --no-dupchecks is recommended as a baseline for these wallet types.
CPU usage
BTCRecover defaults to using as many threads as there are logical CPU cores and runs at the lowest possible CPU priority to minimise disruption to your system.
Use --threads to reduce parallelism if you need to limit CPU usage:
python3 btcrecover.py --wallet ./wallet.dat --tokenlist tokens.txt --threads 4
--no-dupchecks, is often the best way to find the optimal configuration.
Pre-start benchmark
Before the main search begins, BTCRecover runs a short benchmark to estimate how fast passwords or seeds can be checked on your system. This improves ETA accuracy but adds a noticeable delay for some wallet types.
By default the benchmark runs for approximately 30 seconds. You can shorten or skip it:
# Limit benchmark to 10 seconds
python3 btcrecover.py --wallet ./wallet.dat --tokenlist tokens.txt --pre-start-seconds 10
# Skip the benchmark entirely
python3 btcrecover.py --wallet ./wallet.dat --tokenlist tokens.txt --pre-start-seconds 0
# Alternative flag to skip
python3 btcrecover.py --wallet ./wallet.dat --tokenlist tokens.txt --skip-pre-start
Autosave and restore
Use --autosave to checkpoint progress to a file at regular intervals. If the process is interrupted, resume it with --restore:
# Start a recovery with autosave
python3 btcrecover.py --wallet ./wallet.dat --tokenlist tokens.txt \
--autosave recovery.file
# Resume after interruption
python3 btcrecover.py --restore recovery.file
scp or WinSCP to copy them between machines. This is also useful when coordinating cloud GPU instances — you can optionally start a run locally through the counting phase, copy the autosave file to the cloud instance, and resume there to avoid re-counting.
Security considerations
BTCRecover does not protect sensitive data the way wallet software does. Read the following carefully before running it on a machine with access to your actual wallet or on shared or cloud hardware.
Tokenlist exposure
You must create a tokenlist file containing fragments of your password. This file is stored as plain text on disk and is not encrypted. Treat it as sensitive and store it securely.
No secure memory overwrite
BTCRecover makes no attempt to overwrite sensitive password information in RAM during or after a run. Password fragments remain in memory until the process exits and the OS reclaims the pages.
Swap file exposure
Unless you use --no-dupchecks, a large volume of password candidates is held in RAM temporarily. This data is not securely wiped and is very likely to be swapped out to the paging file, where it could remain accessible long after BTCRecover exits.
Recommendations
- Always work on copies of your wallet files. Although BTCRecover is unlikely to modify a wallet file, running it against a copy removes all risk of accidental corruption.
- For high-security situations, consider running BTCRecover inside a virtual machine on a hard disk drive (not an SSD). Securely delete the entire VM once the recovery is complete. This limits swap exposure and makes forensic recovery of password data substantially harder.
- When renting cloud instances, use a wallet extract (
extract-bitcoincore-mkey.py, extract-blockchain-main-data.py, etc.) rather than uploading the wallet file itself. An extract contains only enough data to verify a password — no private keys or addresses are included.