Does the text start with "U2F" and look something like this:

If so, then it could be a MultiBit .key file... which means it is AES256 encrypted text... if you don't know the password, then you'd have to attempt to bruteforce it... which could be problematic if your dead friend used a long complex password.

Your options would be btcrecover (https://github.com/3rdIteration/btcrecover/) or hashcat (https://hashcat.net/hashcat/) and use the "multibit2john" script to extract the hash from the .key file and then bruteforce the hash using hashcat.

Are you wanting the code to be updated for the private key to address converter that this thread was originally about... or for the "address to pubkey" converter that gsciservices was looking for?

For the former... You don't need to bother with opening a file and writing the output in the Python script itself. Simply redirect the output of the script to a file from the commandline... ie. for linux:

Windows supports something similar.


If you're wanting the address to public key... well as pooya87 noted, it's asking the impossible if the address has not been "spent" from... you cannot go from address -> public key as public key -> address uses one way hash functions.

Ahhhh, in that case, I suspect that the "1L5s" address might have actually been in the old wallet as a "watching only" address... and the wallet didn't contain the private key for it.

It's also possible that the file was just damaged and the private key data was unable to be extracted.

Correct... Bitcoin Core is basically bitcoind with a pretty GUI on top... so anything that Bitcoin Core would do, bitcoind would also do.

In any case... if you can see the private key for the address you're after... what is the issue? Can't you just go and import this key into a wallet of your choosing and recover the funds?

Or are you just trying to work out the technical workings of Bitcoin Core and how it goes about updating wallet files?

bitcoin-cli is just the way to interact with bitcoind... it passes the commands to the bitcoind daemon and then returns the responses to you.

The wallet would already need to be loaded by bitcoind (which is essentially the same as having it loaded via the Bitcoin Core GUI) for the walletpassphrase option to work. Same with using dumpwallet with bitcoin-cli... the wallet would already need to be loaded by bitcoind.

Yes, you can refer here: https://electrum.readthedocs.io/en/latest/seedphrase.html

Additionally, when converting from mnemonic phrase to actual seed... Electrum uses the fixed string "electrum" rather than "mnemonic" as the beginning of the mnemonic passphrase.

Ie. if you "extend seed with extra words"... the passphrase becomes "electrumMyExtraWords"... whereas, with BIP39, it is "mnemonicMyExtraWords"

Is the hex view from before or after it has been upgraded by Bitcoin Core?

Interestingly... the "1Cni" address that you show actually has a date of 2016... So, I'm wondering if this wallet was already "updated" at some point AFTER 2013.

I suspect the old keys from 2013 were just never used, and now that the wallet was upgraded, they were given "bc1" addresses in the wallet dump (as that is what Bitcoin Core defaults to now).

You could possibly test this, by taking a copy of the original wallet.dat that has not been opened in a new version of Bitcoin Core... and then loading it into Bitcoin Core, after starting Bitcoin Core using the -addresstype="legacy" and -changetype="legacy" options set (or addresstype="legacy" and changetype="legacy" in bitcoin.conf).

Then check the dumpwallet output to see if the 2013 keys are labelled with "1"-type legacy addresses instead of bc1 addresses.

So after a full (slow) sync in BRD it is showing the full 0.38 BTC that you expect to see?   But Electrum and Fast Sync were showing smaller balances?

Electrum hasn't stored BIP39 seeds since forever... it creates the xprv and stores that in the keystore in the wallet file.

It's the reason why the "Wallet - Seed" option in the GUI is greyed out once you have restored a BIP39 wallet. I vaguely recall seeing somewhere once that the reasoning was because restoring a BIP39 seed was to be able to recover funds and move to a new wallet... not to use the BIP39 wallet on an ongoing basis.

Do the squares actually have any text/characters/numbers in them? Or is it just a 5x10 grid of coloured squares?

If they have characters... what sort of character set do you see? Is it only HEX (0-9A-F) or is it all alphanumerics?

It would appear the old wallet.dat only had one key in it... I'm not sure if the old versions of Bitcoin Core always had a keypool of 100, or if it originally just generated keys/addresses on the fly.

It's also possible the wallet.dat was modified to delete keys... and/or it is actually a "recovered" wallet.dat from your many attempts at using PyWallet that only had 1 legacy key/address loaded in it.

Once you opened it with the latest version, it would have been loaded up with a new keypool of 1000 (which would have defaulted to the bech32 addresses) which would explain why the filesize changed.

Opening a "non-encrypted" wallet with a new version of Bitcoin Core does not automatically encrypt the wallet... you would need to explicitly set a passphrase using the "Settings -> Enncrypt wallet" option in Bitcoin Core. Also, note that "encrypting" a Bitcoin Core wallet does not actually encrypt the entire contents of the wallet (like Electrum does). ie. it is not a full file encryption... it is only the private key data that actually gets encrypted.

What makes you think the wallet.dat should have been encrypted?

So you got an old HDD working... and then deleted your old wallet.dat?


Then you managed to recover the deleted wallet.dat... but before you recovered that deleted file, you had already installed Bitcoin Core and run it?


I'm a bit confused by what you've done... and what you actually have now... do you have TWO wallet.dat's? one from the recent install where you had the blockchain on the different drive... and the old "recovered" wallet.dat... or you do just have one wallet.dat?


Possibly either the passphrase for the Bitcoin wallet, but unlikely as encryption was added in September 2012 with version 0.4.0: https://bitcoin.org/en/release/v0.4.0 and you say your wallet was from 2010... or the 4 words could also have been a "brain wallet" used to generate the private key that was also written on the paper...

In either case, it's relatively moot, as you threw the piece of paper away

The most important consideration when making the backtup is to make sure that either:

a. You shutdown Bitcoin Core before attempting to make a backup copy of the wallet.dat file
or
b. You use the "Backup wallet" option within Bitcoin Core to make a backup copy of the wallet.dat file


If you make a copy while Bitcoin Core is busy writing data to the file, your backup copy might be corrupt and/or missing data... which could be catastrophic if you ever need to recover using the backup!

By shutting down Bitcoin Core (or using the wallet backup option within the app), you can be sure that the wallet.dat file will not be in use when you make the backup copy.

All wallet.dat's are Berkeley DB's... but not all Berkeley DB's are wallet.dat's...

That is to say, just because you found a "random" .dat file that is a BerkeleyDB formatted file, does not mean it is a wallet.dat... what sort of filenames did these recovered files have? or did the recover software just find "random" file names?

Has your friend been actively using that HDD since the file was deleted over 10 years ago??!? (from 2009/2010) If so, the chances of recovering anything useful from "deleted files" is pretty much zero

Or has the old HDD just been sitting around gathering dust?

If you mean for using the recovery feature of PyWallet, then the answer is no... you have to provide a passphrase for the script and it creates encrypted wallets.

So, you only have 1 address... that starts with a "3", correct? And you've only ever received payments to this address, correct? If so, you don't have a mix of "inputs".

You will only have nested Segwit UTXOs... it doesn't make any difference what address types the funds came from... you can receive from "1"-type, "3"-type or "bc1"-type addresses... but as long as you received all your funds to that one "3" address that you generated using segwitaddress.org, then your balance will be made up entirely of p2sh (aka nested) SegWit UTXOs.

So, you don't need to worry about creating multiple wallets or anything.

Personally, I would setup the Ledger... then connect it to Electrum... then sweep the paper wallet using Electrum+Ledger. That will put all the funds directly into the Ledger in one transaction and minimise exposure of your private key etc.

Theoretically, you should be able to setup your Ledger with Electrum... then sweep the UTXOs directly to your Ledger without needing to import them or create other wallets.


If you don't mind me asking... how did you end up with a mix of input types when you have "a p2sh SegWit BTC paper wallet"? When you created the paper wallet did you also derive all 3 address types from the one private key and then sent coins to those addresses over time?

You're wasting your time trying to open these files in a text editor and find anything useful... they're binary data files.

As far as I can tell, the .tlb is most likely a "Type Library Binary" refer: https://docs.microsoft.com/en-us/windows/win32/com/type-library-viewers-and-conversion-tools

It just contains information on the various programming language objects that the application used and the various functions/methods that could be called. It is not a wallet and will not contain any wallet information.


The .dat file is likely also a binary file of some description... but it is impossible to say what the data format is... .dat is a very generic extension that a lot of different applications use to store data in. I doubt it is the same format as a "wallet.dat" from Bitcoin Core... and I would guess that the similarity between what you see in the text editor and an "ECDSA" key is just coincidence.

It *might* be some form of Base64 encoded text... but without seeing the full data it is impossible to tell...

In any case, you'd likely need the original application executable to do anything meaningful with these files... and it appears you only have the data files and not the application itself and I cannot find any reference to any "Bitsave" wallet application on the web.

If you never deposited money to Freebitco.in, or you deposited from an exchange account or other service where you do not control the private keys, then you will not be able to sign a message from that address.

You have had an account on here since 2018, but obviously have not been active and have never staked an address or listed publicly a wallet address that you own.

You will need to talk to their support and advise them of this and see what other options you have for account recovery. In any case, posting in this thread is NOT what you should be doing.