Then how, other than waiting another 4 weeks for the latest Bitcoin Core to sync?

Found that it won't import private keys so I guess I need private key to WIF converter.

Rather than use Bitcoin core to get my keys from a wallet I tried this script posted by @sopaXT in thread https://bitcointalk.org/index.php?topic=2619534.msg26661685#msg26661685

What I got back was a list of bitcoin addresses followed by their private keys.

Noob question, in Electrum when it asks for keys do I provide both the private and public key?

In Electrum I am at the import screen that says:
"Enter a list of Bitcoin addresses (this will create a watching only wallet) or a list of private keys"

I just want to get my balance from all these addresses.

thx

With Bitcoin Core v0.15.1, the old wallet.dat files I could try each of them by copying wallet.dat to this directory?

C:\Users\{user name}\AppData\Roaming\Bitcoin

I did this with one of them and some how my wallet went from one key that was 16k to 2400 keys with a size of 2400k.  But it has not synced yet so balance is 0.  When I dump keys with pywallet they do not look like bitcoin addresses though.  They look like sha64?

Rather than waiting weeks for this thing to sync, could I copy each of these addresses to blockchain info and I think it is called sweep to determine the balance?

pywallet has not recovered any keys from any of the chunks from the grep or from any of the disks.  It creates recovered_wallets and partially_recover_wallets but without keys.  I will try the manual WIF key conversion on the data as you described.   thx

They are 30 characters unfortunately and pywallet against the text file I created through grep does not get them out.  I tried db_recover, no good.  Also tried your dump keys program from here https://bitcointalk.org/index.php?topic=2619534.msg26661685#msg26661685

Is this the kind of thing you add two characters to the beginning like 08, gives you 32 and then you convert the keys to Bitcoin format and do something with converting the pair, or the other way around?

Any ideas?

edit: maybe they are 32 with the Berkerley DB masking the last two characters as ^@  or the first as   or ^]

Will try that to but I think those key names like keymeta are for later code? Not February/March 2009 and 2010?

Anyway I tried the grep above and I am getting chunks of some sort of keys back.  There are a repeating sequence of 30 characters which looks like shortened SHA followed by 8 garbage characters followed by another set of 30 character SHA.

Anyone familiar with grep?  Does this look right?

grep -i -a -B10 -A100 --binary --text --perl-regexp 'fd1701308201130201010420' /dev/sda1

I thought I found one but no. What do you think of pywallet 2.2?  Does it really cover all the hex and handle fragments on an hd for that period?  I have used that most on every hard disk.

I did start out with recurva, nothing relevant in deleted files. Then tried photorec, they even had a signature Bitcoin Armory wallet, not sure if that was the same, but tried it along with a hex that was different from the one above.  Was thinking of going back through the disks with winhex trying the hex above, but if pywallet covers them all then what is the point I guess.  Already been at it for weeks, going insane over it.

If I only find a private key does that get me anywhere?

I have it mounted separately so nothing is going to get written to it since grep is being executed from the boot disk, any temp files or output by grep will be written there.

What about that second part, about the encryption, is it all just unencrypted Berkerely DB prior to 2011? (I do not remember it that way, maybe I am confusing converting it from text to berkerely DB why I thought it was encrypted and mistaken about password encrypted - faulty memory)

Does this look right?

grep -i -a -B10 -A100 --binary --text --perl-regexp 'fd1701308201130201010420' /dev/sda1

Doing some research I just read a blog that says wallet encryption was not until version 0.4.0 on September 23, 2011?

If that is correct does that mean the wallet.dat before that date are plain text or still Berkerely DB?  If it is in Berkerely DB would that mean I could retrieve the entire wallet including all keys by simply using db_dump.py on a found wallet.dat file?

thx

Hi, I have a few questions in my long shot to recover lost mined coins from 2009 and 2010. The hard disks I am searching through have since been overwritten with Linux ext3 partitions, NTFS or FAT32. I have tried Recurva no luck and photorec but was unsure whether the contents were just some other program using Berkerely DB.

So my questions are:

1. I have also been using pywallet 2.2 in this fashion:  pywallet.py --recover --recov_size {disk size}Gio --recov_device={partition} --recov_outputdir={working directory}

Does pywallet 2.2 sufficiently cover 2009 and 2010? It is finding allot of files but reports 0 encrypted or 0 unencrypted keys.

2.  For an unencrypted wallet file what would be the ideal text or hex pattern I should be searching for that period?  Much of the info I am finding here is for later recovery and from what I understand the format changed a bit.  I suppose if someone could post an unencrypted example from back then of parts that never change, that would be ideal. (not much luck finding samples here, or Bitcoin.com or google).

3.  Same question as #2 but for an encrypted wallet file.  Going from memory I remember I could read what I mined in a text file assuming wallet in 2010 and 2009 I remember doing something where I could no longer read the file, assuming password encrypted.