Problems with dumping all the contents of an old .dat wallet

[ThisUsernameSucks]

I have this old wallet.dat file, originally created in Bitcoin Core around 2015-2016. Now, I'm trying to move all my Bitcoins from this wallet into an Electrum wallet because I simply cannot get Bitcoin Core to sync and load my wallet without problems (I've tried on several different platforms with different errors, and I've given up on this route for the time being).

Anyhow, my mission is to export all private keys containing unspent transactions so that I can sweep them into Electrum. The first thing I did was to make a wallet dump using jackjack-jj/pywallet. This gave me all the addresses starting with "1", some of them contained in the list of receive addresses in Bitcoin Core and some of them being change addresses I assume. However, some receive addresses, starting with "3" were obviously missing from this dump.

So, I fired up a fresh install of Bitcoin Core and used the dumpwallet command to export all my keys. This gave me a lot of addresses beginning with "3", including the missing receive addresses from the pywallet dump. However, not all addresses beginning with "1" that I found using the pywallet dump showed up for this Bitcoin Core dump.

So, what I'm left with are two non-identical subsets of keys, and I don't know if there are more that I haven't been able to retrieve. However, if I were to understand why the two programs gives me different outputs, maybe I would be more confident that I've located them all.

First of all, I don't know why I have a mix of addresses starting with "1" and addresses starting with "3". Without really knowing, it seems like my wallet is some kind of mix between a HD wallet (generating addresses starting with "3"?) and an old wallet where each address is generated individually (addresses starting with "1"?). Since my wallet dump from Bitcoin Core is filled with certain concepts suggesting a HD wallet (for example, derivation paths and master private keys), I guess this is the case. If so, I still don't understand why Bitcoin Core won't dump all of the keys that pywallet can find. At least pywallet feels more consistent, since I only get addresses starting with "1" (I guess support for addresses starting with "3" are lacking).

Further, there are two things I really don't understand. If I have a HD wallet, shouldn't I be able to generate an infinite number of addresses? I realize that Bitcoin Core can't print all of them since I don't have an infinite hard drive, but how is it decided which ones that will be shown? Some kind of internal track record of all my transactions? Also, when reading the wiki page about addresses starting with "3", it says "To spend bitcoins sent via P2SH, the recipient must provide a script matching the script hash and data which makes the script evaluate to true." Does this mean that the private key contained in my dump from Bitcoin Core won't be enough?

Sorry for this brain dump about my wallet dump, but I've been looking into this for months now. I would really appreciate any help. In the end, the only thing I really want to do is to get an exhaustive list of all public-private key pairs contained in my wallet (including change addresses). From the, I can write a script myself that checks the balance of each of these public addresses.

[1713897293]

1713897293

[1713897293]

1713897293

[1713897293]

1713897293

[nc50lc]

You can import the prv keys in Electrum with a prefix to indicate the script type of the addresses you want to derive.
In Electrum - "Import bitcoin addresses or private keys": add p2wpkh-p2sh: before each of the private keys to import them as '3' addresses; you can leave them without a prefix for '1' addresses.

Example (will produce both '3' and '1' address of the same prv key):

Code:

p2wpkh-p2sh:KxAz8kcuWebno5cjRTWS2i......
KxAz8kcuWebno5cjRTWS2i......

Further, there are two things I really don't understand. If I have a HD wallet, shouldn't I be able to generate an infinite number of addresses? I realize that Bitcoin Core can't print all of them since I don't have an infinite hard drive, but how is it decided which ones that will be shown? Some kind of internal track record of all my transactions? Also, when reading the wiki page about addresses starting with "3", it says "To spend bitcoins sent via P2SH, the recipient must provide a script matching the script hash and data which makes the script evaluate to true." Does this mean that the private key contained in my dump from Bitcoin Core won't be enough?

You can generate an infinite number of keys with your HDSeed but there's no reason to show or preload the rest if you're not needing them.
Bitcoin core will only pre-load 1000 of each of your internal (change) and external keys to its keypool, those are the contents of the dump file.
The address type in the dump depends on the address type you're using in bitcoin core but it's actually capable of using all address type of those keys.

If you import them to Electrum as p2sh-SegWit, it will be able to spend from them since it can easily recreate the redeem script from the private key.

[HCP]

So, what I'm left with are two non-identical subsets of keys, and I don't know if there are more that I haven't been able to retrieve. However, if I were to understand why the two programs gives me different outputs, maybe I would be more confident that I've located them all.

Pywallet will (should) find all your private keys but will only output showing them as P2PKH (aka "Legacy") addresses... whereas Bitcoin Core supports using P2PKH, P2SH-P2WPKH (aka "Nested Segwit") and P2WPKH (aka "Native Segwit") addresses from your private keys.

Chances are that the list of private keys will be the same between the pywallet output and the Bitcoin Core dump... it'll just be the list of addresses which is different.

I would suggest looking at the sets of WIF keys displayed from each and checking that they are the "same". Note that they may not be output in the same order... I know that the dumpwallet in Bitcoin Core doesn't usually output them in derivation path sequence order... not sure about Pywallet.

[ThisUsernameSucks]

Pywallet will (should) find all your private keys but will only output showing them as P2PKH (aka "Legacy") addresses... whereas Bitcoin Core supports using P2PKH, P2SH-P2WPKH (aka "Nested Segwit") and P2WPKH (aka "Native Segwit") addresses from your private keys.

Chances are that the list of private keys will be the same between the pywallet output and the Bitcoin Core dump... it'll just be the list of addresses which is different.

I would suggest looking at the sets of WIF keys displayed from each and checking that they are the "same". Note that they may not be output in the same order... I know that the dumpwallet in Bitcoin Core doesn't usually output them in derivation path sequence order... not sure about Pywallet.

Sorry, I don't quite follow. Are private keys associated with both legacy public addresses and new public addresses supporting things like Nested and Native Segwit?

[nc50lc]

-snip-

Sorry, I don't quite follow. Are private keys associated with both legacy public addresses and new public addresses supporting things like Nested and Native Segwit?

For Bitcoin core, you can refer to my post above HCP's reply:

-snip-
The address type in the dump depends on the address type you're using in bitcoin core but it's actually capable of using all address type of those keys.

(referring to dumpwallet result)
For other clients, it depends, but most of them should have a feature to indicate the address' "script type" when importing private keys.

[NotATether]

Sorry, I don't quite follow. Are private keys associated with both legacy public addresses and new public addresses supporting things like Nested and Native Segwit?

A private key not only has a legacy P2PKH address associated with it, it also has a "3" P2SH nested address and "bc1" P2WPKH segwit address which all have the same public key hash.

Bitcoin scripts works in terms of public key hashes, and not addresses, where no matter which script type the address is, it will always check the sending bitcoins against these 160-bit hashes.