Recovering an old wallet

[oodog]

Hi all,

I have an ancient (circa 2013) bitcoin core wallet containing some funds that I'd like to consolidate.  Ideally, I'd like to just import the keys into an electrum wallet, but I've been unsuccessful in doing so.

-  I long ago recorded the address in the wallet that contains the funds.
-  I was able to export the private keys using pywallet.
-  I can import the keys into electrum, but it shows a zero balance and doesn't show the address that has the funds.
-  Likewise, running bitcoin-tool against the private keys produces addresses but not the one that has the funds.
-  I can't migrate the wallet into a pruned bitcoin core instance because the last wallet sync goes beyond the pruned data.

So my questions are:

1) Why don't I see the correct address generated from my private keys?  Would there be some other key that pywallet couldn't find or is pywallet somehow generating the private key wrong?  Is there a better tool?  (btcrecover also seems fairly out of date)
2) Is a complete reindex (downloading the entire blockchain again over the course of several days) likely to work?  It seems like it wouldn't if, for some reason, the private key is not associated with the wallet.

Any assistance appreciated  

[OmegaStarScream]

I'm not familiar with bitcoin-tool but when importing to Electrum, is the address in a different format (does not start with "1") compared to the ones you had on Bitcoin core? or it does start with 1, it's just not the same address?

You also said that loading the wallet.dat on Bitcoin core is not doing much. Do you get any errors when you open the wallet (even if you have not fully synced)? or you can clearly see the receiving addresses, but it's just not the ones you had?

[oodog]

I'm not familiar with bitcoin-tool but when importing to Electrum, is the address in a different format (does not start with "1") compared to the ones you had on Bitcoin core? or it does start with 1, it's just not the same address?

All of the addresses in Electrum are the same format ("1" prefix) but the address I'm expecting is not among them.

You also said that loading the wallet.dat on Bitcoin core is not doing much. Do you get any errors when you open the wallet (even if you have not fully synced)? or you can clearly see the receiving addresses, but it's just not the ones you had?

When I "migratewallet" I get the error:

Code:

Wallet loading failed. Prune: last wallet synchronisation goes beyond pruned data. You need to -reindex (download the whole blockchain again in case of a pruned node)

Because, well, pruned node   I could attempt the reindex, but I find it curious that I can't seem to regenerate the correct addresses from the wallet (and reindexing is going to take a few days and a whole lot of system resources).

[joniboini]

All of the addresses in Electrum are the same format ("1" prefix) but the address I'm expecting is not among them.

Have you verified if you're using the same WIF key? I remember reading a similar experience in my local board where someone mistakenly imported a compressed key even though they have the funds on the uncompressed one in Electrum. CMIIW.

[oodog]

All of the addresses in Electrum are the same format ("1" prefix) but the address I'm expecting is not among them.

Have you verified if you're using the same WIF key? I remember reading a similar experience in my local board where someone mistakenly imported a compressed key even though they have the funds on the uncompressed one in Electrum. CMIIW.

I was wondering about that, also, but it looks like both the compressed and uncompressed keys are present in the import.

[DireWolfM14]

I've never used pywallet, does it automatically parse through change addresses also?  Of the addresses you are able to import into Electrum, do they show familiar transactions, indicating they are part of the same wallet?  It might be a range issue if you used many addresses in the wallet, and pywallet is only extracting a limited number of keys.  Again, since I've never used pywallet I don't know if this is an issue or not.

[oodog]

I've never used pywallet, does it automatically parse through change addresses also?  Of the addresses you are able to import into Electrum, do they show familiar transactions, indicating they are part of the same wallet?  It might be a range issue if you used many addresses in the wallet, and pywallet is only extracting a limited number of keys.  Again, since I've never used pywallet I don't know if this is an issue or not.

I don't know what pywallet parses.  It seems to do different things depending on its determination of the wallet type, in fact producing different output for different wallet types (!!!),  It's highly suspect.

I'd be happy to try a better tool if anyone can recommend (an open source, auditable) one.  I've avoided btcrecover because it appears to rely on python2.7, and I'd prefer not to open that can of worms.  I think my next step is going to be to try to hack bitcoind to spit out keys/addresses for a wallet during migration, before it runs into the error.

EDIT: I should have added that the Electrum addresses show no transactions whatsoever.  Considering that I'm seeing 186 keys and that this was a "test" wallet that probably only saw a handful of transactions, I don't think it's a range issue.

[Cookdata]

When I "migratewallet" I get the error:

Code:

Wallet loading failed. Prune: last wallet synchronisation goes beyond pruned data. You need to -reindex (download the whole blockchain again in case of a pruned node)

You can migrate your old wallet and work around this error. This is similar to this pull request 35266. You need to add load_wallet argument = "false", this way your old wallet will be able to migrate and won't load, and this error will not show again with your pruned node.

Since you have a pruned synced node, you can't load it with the migrated wallet, you still need a full node to be able to load the new migrated wallet.

Because, well, pruned node  I could attempt the reindex, but I find it curious that I can't seem to regenerate the correct addresses from the wallet (and reindexing is going to take a few days and a whole lot of system resources).

If you have the resources, why not give a full node a try and reindex since you have not found a solution yet.

[DireWolfM14]

I'd be happy to try a better tool if anyone can recommend (an open source, auditable) one.

Yeah, Bitcoin Core. 

I think your best bet might be to bite the bullet and reindex core with your wallet in place.  If you have a fast nvme drive it could be done is as little as 30 hours or so.

[oodog]

If you have the resources, why not give a full node a try and reindex since you have not found a solution yet.

Ok, so this is interesting.  I had hoped to avoid reindexing because I expect it to take several days and even the "pruned" sync rendered my system unusable while running.  But then I accidentally started a "reindex" anyway and found I couldn't get back to a "pruned" state after that so I started looking at flags to at least make the indexing a little less onerous.  I came upon "-reindex -assumevalid=<fairly-recent-block-hash>", started the node and now "migratewallet" completes successfully!  And, sure enough,   listreceivedbyaddress shows the address I was looking for (no balance yet, as it hasn't synced past 2013 yet).

Thank you all, you've all been very helpful!  I'll post an update on this topic once I manage to either get the key migrated or funds transferred.

[Cookdata]

If you have the resources, why not give a full node a try and reindex since you have not found a solution yet.

Ok, so this is interesting.  I had hoped to avoid reindexing because I expect it to take several days and even the "pruned" sync rendered my system unusable while running.  But then I accidentally started a "reindex" anyway and found I couldn't get back to a "pruned" state after that so I started looking at flags to at least make the indexing a little less onerous.  I came upon "-reindex -assumevalid=<fairly-recent-block-hash>", started the node and now "migratewallet" completes successfully!  And, sure enough,   listreceivedbyaddress shows the address I was looking for (no balance yet, as it hasn't synced past 2013 yet).

Thank you all, you've all been very helpful!  I'll post an update on this topic once I manage to either get the key migrated or funds transferred.

Glad you saw the address 

If you have fast internet speed and bandwidth, you should fully sync in 2 days or less.

[oodog]

So I've managed to obtain the correct private key for the address and have transferred the funds to a more modern wallet.  Doing so was straightforward:

1) "getaddressinfo" on the address provided a json record for the address including a "parent_desc" field.
2) "listdescriptors true" provided the private descriptors.
3) I looked up the private descriptor based on the bracketed identifier in "parent_desc", the base58 identifier next to it was the private key (e.g. "combo([identifier]private_key)") 

I was able to paste this key into Electrum, create a wallet and transfer the funds.

I don't expect this exact process will necessarily work with all key types, it looks like modern keys might be a little more complicated.

Also, by way of full disclosure, I should point out that I did all this with a slightly modified bitcoin core daemon.  When I initially tried to migrate the wallet, I was getting an error because the wallet lacked a "best block locator record."  This is an issue that was ostensibly fixed (see https://github.com/bitcoin/bitcoin/pull/34198) but seemed to still be causing problems during the export of the migrated wallet.  The following patch (against commit ca7162cde58e69214a3309c17fac6d666b5f055a)  fixed it for me locally:

Code:

diff --git a/src/wallet/export.cpp b/src/wallet/export.cpp
index 9f9a9486db..e23cb93c11 100644
--- a/src/wallet/export.cpp
+++ b/src/wallet/export.cpp
@@ -149,13 +149,12 @@ util::Result<std::string> ExportWatchOnlyWallet(const CWallet& wallet, const fs:
             CBlockLocator best_block_locator;
             {
                 WalletBatch local_wallet_batch(wallet.GetDatabase());
-                if (!local_wallet_batch.ReadBestBlock(best_block_locator)) {
-                    return util::Error{_("Error: Unable to read wallet's best block locator record")};
+                if (local_wallet_batch.ReadBestBlock(best_block_locator)) {
+                    if (!watchonly_batch.WriteBestBlock(best_block_locator)) {
+                        return util::Error{_("Error: Unable to write watchonly wallet best block locator record")};
+                    }
                 }
             }
-            if (!watchonly_batch.WriteBestBlock(best_block_locator)) {
-                return util::Error{_("Error: Unable to write watchonly wallet best block locator record")};
-            }
 
             // Copy the transactions
             for (const auto& [txid, wtx] : wallet.mapWallet) {

This may have only been a problem because my node didn't have a full copy of the blockchain (perhaps this record gets filled in during migration for a system that does).  If anyone thinks it's worth reporting, I'll open an issue with the core devs.

Thanks again, all, for your help!

[nc50lc]

This may have only been a problem because my node didn't have a full copy of the blockchain (perhaps this record gets filled in during migration for a system that does).  If anyone thinks it's worth reporting, I'll open an issue with the core devs.

Which Bitcoin Core version is it based on?
Because that pull request is just recently merged so older versions of Core do not have that patch.

I don't expect this exact process will necessarily work with all key types, it looks like modern keys might be a little more complicated.

It just needs a few additional characters for other script types that Electrum supports.
Just click Electrum's tooltip; "Info" button during Private key import/sweep.