Interesting, I was certain that Bitcoin Core displays an error/warning if you load an old wallet into a "pruned" node warning that it may not be displaying the correct history/balance etc... although I might be confusing it with the warning you get if you "unload" a wallet.


You may not even need to wait that long... if you have the wallet loaded now (while it is syncing)... it will find the transaction history as it goes along processing blocks. So, once you get past the 2015 blocks (when you think you stopped using the wallet), it should show the "correct" balance.

Obviously, that may not be the case if the wallet was used after that time.. but hopefully, you'll be able to see the transaction history/balance updating as it syncs... which should give you some idea of what happened to the coins.

In any case, once it has finished syncing fully, you can be fairly certain that the balance showing is "true and correct".

Firstly: you should make some copies of your ".wallet" file and work on copies of the file, rather than the original. Better safe than sorry!

You might find that you have to figure out how to compile the application yourself... as all the old binary files were deleted recently from the old multibit website

One problem you might face, and I don't think it has been confirmed as an actual bug, is that if the file encryption process was "bad" and the encrypted data was either "junk" or written incorrectly, then trying to decrypt it might be "impossible", regardless of whether or not you have the correct passphrase!!?!

Note that this should theoretically not have been possible, as the app supposedly attempted to immediately decrypt the encrypted data using the same key and only returned a "success" result if it was possible. However, based on the numbers of people who have had issues trying to decrypt old MultiBit wallets, something definitely isn't quite right.

Have you tried using either:
The "read-multibit-wallet-file" tool released by the MultiBit devs: https://github.com/Multibit-Legacy/read-multibit-wallet-file - EDIT: Possibly nonfunctional, use at own risk
or
One of my multibit recovery scripts: https://github.com/HardCorePawn/multibit_recovery (specifically: "decrypt_multibit_classic_walletkeys.py")

Which would probably be true if you had a pre-existing list of all the seed word permutations and/or seed value...

But I ran into memory issues attempting to pre-compute everything, so it has to generate each permutation, then attempt to convert it to a seed while checking the checksum etc... I'm sure the way the algorithm is generating the seed permuations is probably pretty poor. It's basically just iterating some lists.

The "library" I'm using for testing the validity of the mnemonic itself should not be too bad, it's the "to_entropy()" function from the Trezor "python-mnemonic" code: https://github.com/trezor/python-mnemonic/blob/master/mnemonic/mnemonic.py#L125

But I'm sure there are probably ways to make that more efficient.


For what it's worth... the script finished overnight:
21hrs and "found" 1,049,432 valid seeds


interestingly... the last 12.5 million or so seed permutations didn't create any valid seeds:
I guess the limited number of words available in position 12 just didn't make any valid checksums with the other available words!

If I'm understanding what you're writing... you have something like:

- possible_word1(list of ~4-10 words)
- possible_word2(list of ~4-10 words)
- possible_word3(list of ~4-10 words)
...
- possible_word12(list of ~4-10 words)

and from the sounds of it, you actually 13 words? so, this is the "old" electrum seed format?

Anyway, assuming just 12 words for now, your possible seed combinations are: #word1_words * #word2_words * #word3_words * ... * #word12_words. Doesn't sound like much, until you do the math... even with "best case" of just 4 possible words in each position... that's 4^12 or 16,777,216 permutations.

Rough experience tells me that around ~6% of those will be "valid" (ie. the checksum matches)... so you're looking at something like ~1,006,632 "valid" seeds that you'd need to check for a match against your public address.


Anyway, I wrote a quick python script that takes in 12 files named 1.txt, 2.txt, 3.txt, ..., 12.txt (for my demo, each file has only 4 words) and then just iterates through the words in each position... it generates over 10,000 seeds/minute... and is finding (as expected) slightly more than 6% of those to be "valid".

So, at ~10k seeds/minute... maybe ~1677 minutes to go through the full search space (only 4 words per slot, 12 slots)... which is around 28hours.

The main slow downs will be:
- More words in a given position... that's going to ramp up the total search space
- Actually generating private keys/addresses to check, as these are computationally a lot slower than just checking if a seed is valid.

With some optimisation, and maybe porting to C or something faster than Python, you'd probably gain some performance benefits... I'm sure it's in the realms of reality to be able to do it within a matter of days? It really depends on how big your search space is... what are the exact number of words you have in each position?

Note that because of this:
Doing a "rescan" is going to be a painful experience for you... Bitcoin Core can't rescan on block data you don't have... you've pruned your wallet, so only the last 2 Gigs worth of blocks (ie. 2020-2021 data) will be available.

So a "rescan", for you, is going to trigger a full redownload of the blockchain!


Question: Did you fully sync Bitcoin Core first... and then load the old wallet.dat? If you loaded the old wallet file after your node had finished syncing, then Bitcoin Core will not have been able to update the wallet transaction history/balance correctly... as you're running a pruned node.

If you right click the transaction and select "copy transaction id"... then search that transaction ID on blockexplorers like blockchair.com, blockchain.com, btc.com, blockcypher.com etc... do you see anything at all?

The "not in memory pool" part of the status is problematic... it means that the transaction basically does not exist anywhere except in your local transaction history stored in your wallet file.

What happens if you goto "Window -> Console" and enter:

Do you get anything at all? If you get a transaction hex output, you can use:
And it should rebroadcast the transaction... but read the warning about the current state of the network below.


If you don't get a transaction hex... you'll most likely need to use -zapwallettxes command line argument and then rescan the wallet so it can identify and display all the "confirmed" transactions and balance as per the information currently recorded on the blockchain.

You should then be able to resend the transaction if desired... but be warned that after the Tesla announcement and subsequent pump in BTC value, the network is super busy... there are over 100k unconfirmed transactions and fees are in the 100+ sats/byte range again

You're looking at the wrong info... Can't remember what the old versions of Bitcoin QT/Core looked like... but in the newer ones there are two "about" screens:


Which gives:

and



If it's not obvious from the "About..." window... maybe check on the "Information" tab for the client version:

Given that your 12 words are all in the BIP39 list, but giving "invalid mnemonic" (and if you've already tried the "similar word" approach and had no luck) another option might be writing a script that tries all the different permutations of those specific 12 words, looking for "valid" mnemonics...

With a set of 12 words... you're looking at 12! permutations = 479,001,600... and given the way the "checksum" works, not all of those permutations is actually going to be valid.

Unfortunately, I suspect that any given 12 words would generates tens of thousands (if not millions) of valid seed combinations (maybe ~5%? ) So, while getting a script to generating and identify all the "valid" seeds from your 12 words probably isn't that difficult, the trick will be identifying which one of those valid seeds actually has "in use" keys attached to it.

Be aware that you might also have issues getting Electrum to run if you're on such an old macbook... Electrum requires 10.13.x or higher:



But given you have Bitcoin Core 0.21 already installed and synced... you can easily import the private keys into that using importprivkey (or importmulti)... the only downside will be waiting for it to "rescan" the blockchain. So, if you do import into Bitcoin Core, make sure you set the "rescan" parameter on the importprivkey command to false until you import the very last key.

That way, it'll only rescan once... and not every single time you import a key

You'll need to wait for it to sync to show your balance etc. It'll probably take a while (minutes if not hours) as last time I ran it (a few weeks ago) there were only like 4 or 5 "peers". It should eventually sync tho. I would however advise you not to try and send a transaction from the app. It's not able to handle native segwit addresses (aka bech32 aka "bc1"), so if you're trying to send to one of those, it won't recognise it as being valid...

Also, fees were a lot lower back in the day... and MultiBit Classic's fee estimation is horribly out of date... as such, it's liable to send with a very low fee which means your transaction will likely get "stuck" (given the current state of the network)

If you don't want to wait, you can goto the "Tools -> Export Private Keys" option and you'll be able to dump out the private keys... although you have to be careful to use the "Do not password protect export file" option... otherwise, you won't actually be able to read the contents of the export file!



Once you have the private keys export, you can copy/paste them into an Electrum wallet (Use: "Import Bitcoin Addresses or Private Keys") option:


Then paste the private keys (should start with a "5" or "K" or "L") into Electrum.

Electrum should within a few moments... and show your transaction history and balance etc. I would recommend that you then create a "Standard" wallet in Electrum with a 12 word seed mnemonic backup and transfer for you bitcoins to that, as the imported wallet will never generate new addresses... and address re-use is a "bad thing"™

No... any form of compression will modify the actual structure of the underlying data... it has to, otherwise the data can't get "smaller". This will mean that the script will be unable to detect the wallets by inspecting the bytes for the indicators of a wallet file.

It's the same reason why you can't use the "hex string search" method on zip files etc... the data will have changed, and you can't really know how it will have changed... so the "standard" markers you're looking for won't be found...

The only way to do it would be to uncompress the files and then inspect the extracted files... which could be problematic if the archives are encrypted/password protected... and you don't have the password.

Sadly, this is how things are here, on reddit, telegram and pretty much any other crypto-centric forum/messaging service... Whenever anyone asks for "help", especially "newbies"... they're immediately targeted. There are scammers everywhere looking for "gullible" users willing to hand over wallet files or seed phrases etc believing that the "anonymous" internet person is "just trying to help"...

They're trying to help alright... help themselves to other peoples crypto! 

Good for you, being smart enough to say "No, thanks"... however I think your pleas for people to stop messaging are going to fall on deaf ears... it's like asking the Ledger leak spammers to stop.

And if you check the supported list on Ledger: https://www.ledger.com/supported-crypto-assets and enter "pax" into the search box, you can see it is supported:

Only just seen this message... because MultiBit board is "hidden" in Archival... do you still need help recovering your bitcoins?

If you have the .key and .wallet files and you know your wallet password, you'll be easily able to recover your private keys and then import them into another wallet like Electrum to recover your coins.

Honestly, that seems to be some sort of networking issue... not sure why it's syncing the headers so slowly and not downloading any blocks. I'd concur with ranochigo that it looks like some sort of firewall issue.

Yeah... sadly they used to have the .exe's still available for download. Unfortunately, they were all removed at some point over the last year or so

Do you know if it was Multibit Classic or MultiBit HD? What format is the wallet file name is it: multibit.wallet or mbhd.wallet.aes

I have written some scripts that can extract the private keys from these files: https://github.com/HardCorePawn/multibit_recovery
They require Python2 and some knowledge of working on the command line etc.

The MultiBit dev's also released a tool for extracting private keys that uses NodeJS instead of Python: https://github.com/Multibit-Legacy/read-multibit-wallet-file

Alternatively, if it's a "classic" wallet (multibit.wallet), you could try compiling the source code here: https://github.com/Multibit-Legacy/multibit
If it is an HD wallet (mbhd.wallet.aes), you can still get the .exe's here: https://github.com/Multibit-Legacy/multibit-hd/releases


Failing that, I do have a copy of "MultiBit Classic 0.5.19.exe"... but then you'd have to trust that I didn't doctor it, so this should be your absolute last last final last resort

Yeah... on the Trezor ONE, you have to enter via the recovery process on the PC: https://wiki.trezor.io/User_manual:Recovery__T1#Recovery_process

It does only require entering 1 char and will provide a dropdown list of words to select from etc... and in a random word order.

They also have the "advanced recovery" process where you can click in a 9x9 box (similar to the PIN entry) to "type" the word by selecting an incrementally more specific letter sequence... The example they use is entering the word "Heavy", where you select: "H-L" --> "HA-HE" --> "HEA" --> "heavy"... which helps obfuscate things even more: https://wiki.trezor.io/User_manual:Advanced_Recovery

I suspect the bottle neck will be the low RAM and the external SSD... I would wager that the USB port/controller isn't the best (likely USB2.0) and the throughput is probably quite low. The low core clock of the CPU probably isn't helping either.


Not sure if that is going to be helping or hindering or doing nothing... I've never been a fan of Readyboost... and it doesn't really boost your RAM... it is just part of a disk caching system (SuperFetch), that should theoretically be faster in some specific instances than using HDD-based disk caching.


Still, only a couple more days to go!

This has truly been a labour of love!

What CPU/RAM are you using for this? You said earlier you were using a portable SSD, is that correct?

It does not... but if the error causes the underlying script to be invalid, when the wallet attempts to decode and check the script, it'll likely generate errors... or, you might find you just accidentally change that output amount from 0.1 BTC to 1 BTC

It kind of depends where the error occurs... and what bytes were changed by the error... and what they were changed to.

Obviously, this is only an issue with the "unsigned" transaction... after it is "signed" any modifications will break the signature and it will fail to broadcast etc... and with the "unsigned" transaction, you should be double checking all the details before signing it anyway


Or, you could just use a usb stick