Topic: Seeking solutions to a 12 year old Electrum wallet mystery (Read 437 times)

seems pretty easy...
i have tool

Any updates on this? Also curious to the amount of BTC in this wallet given you've spent 12-13 years on this.... I'm a full stack developer with a background in reverse engineering. I'd be willing to work on any projects anyone may have like this for a share of recovered assets.

I have a bunch of different old wallets. Unfortunately I failed to include many notes at all whenever I wrote down a recovery mnemonic. I don't think I compiled that ancient version originally, but it isn't impossible. Also there arw 3rd party tools that used Electrum's codebase (specifically its key derivation) that I used that are no longer supported or maintained so I have no way of knowing exactly which version they were using.

I definitely have some pre-2.0, post-0.39 wallet seeds, for sure. For my own peace of mind, and to cover all my bases, I like to manually derive the keys from mnemonic to verify that they were derived as expected. Ever since the Bip32 "leading zero" bug that affected at least 2 wallets of mine (Copay), I have been sort of paranoid about those types of bugs. Since I still have a few addresses with unspent balances that I lost access to somewhere along the way, i have just been trying to rule out as many seeds as possible via process of elimination. It is relatively easy to do that with Bip39 wallets because there is so much literature out thrre. But with Electrum, especially version 1 and older, figuring out the technical details has proven very challenging. Granted, I'm mot the most technically competent person in the world, but I can usually learn...usually. Lol

That is because the affected versions (pre v0.34) existed before the official release of Electrum.
Only those users who are following its development and used the source code to run Electrum have experienced the bug.
So it's only normal that you cant find any documentation about the issue aside from the old release notes since it's not yet officially released at that time.

If it's just old seed (pre v2.0, post v0.34), then you can simply restore it to the latest versions, it will be accepted as "old seed" and it will restore the same wallet.

If it's for versions before v0.34, you may get better response by asking the core developers about how to reproduce the bug.
You can post it as an issue in Electrum's repo: https://github.com/spesmilo/electrum/issues (be accurate with the title)

Any update on this?  I, too, have long been vexed by the mysterious key derivation bug from the older (pre-0.39) versions of Electrum. Documentation on this bug seems non-existent. I did find some comments from the developer about how very few people were using the software at that time (or something to that effect), which seemed sort of dismissive, to be honest. Even if only 2 people were affected by the bug, you would think they would at least put up some info about it somewhere to help point those two people in the right direction. If such documentation exists, I apologize. I have been unable to find it. I have also been unable to find any documentation that explains how the master keys were derived from "old" seed version (non-bip39 wordlist). There doesn't appear to be a way to export a master private key from those types of wallet. Is that not possible? Does anyone know? Sorry, not trying to hijack your thread. I hope you have had better luck than I.

I once had a recovery challenge with a forgotten spending PIN number of an Android Schildbach Bitcoin wallet that I managed to find with BTCrecover after weeks of number crunching. I say this, that I gained some knowledge with that tool in the process of my recovery problem.

When you finally have a working hardware and software setup, I highly recommend to first solve a known fabricated recovery case similar to your wallet cracking problem. Make it easier so you don't waste too much energy and time but still being of reasonable complexity to verify your solving setup.

Because if you can't solve a case with a known solution, you likely won't succeed with your real wallet recovery problem.

Hey peoples. Just wanted to poke my head in and give an update as to what my latest attempts have lead to. Once again I cannot begin to fathom the amount of invaluable information and assistance I have been given in this new leg of approach and in my entire experience chasing down every lead for years. Thank you all for sharing your time, advice and determination to help me and others along the way.

I am at a much more refined place after I researched all the great information gathered in this thread. We have narrowed down the version of Electrum used, we've also come up with ways to implement varying approaches to BTCrecover but the most important fact we've all but confirmed is this key I'm after behaves in a unique and unorthodox way because of the way it was derived by the Electrum version.

I was able to not only use the "best guess" method for BTCrecover using the Electrum 1.* derivation selection, but I was also able to forge an argument allowing me to use the token file. But then began the problem. Even though I have one of the most powerful PC configs, when this thing went to work with 32 threads, I was just a few degrees short of hitting red. I think my major issue was getting BTCrecover to use GPU acceleration but I've been having issues finding a Debian based distro that uses the proprietary AMD drivers or finding a way for BTCrecover to recognize the CPU and not label the hardware "generic" in the terminal error data.

So now it is a hardware issue that needs to be resolved before I can proceed further. So far, nc50lc, apogio & Pmalek have been exemplary with their spot-on knowledge and when I do get a working method on both the hardware and software end of things, we can move ever more closer to the glorious final resolution.

BTW, some clarifications with the "quite huge search space" for --big-typos 8, based from the uncertain words in the other post.
I mean that it's huge that it's not humanly possible to brutefoce even with your GPU; and for the follow-up,
I can't find other options in seedrecover to set a tokenlist in v1.x electrum seed so it has to rely on "best guess" and "--big-typos", maybe someone else does.

If you can make a bunch of manual "3 mistakes" iterations of your mnemonic phrase based from the know and possible words, that will make it plausible.

Example (now based from this):
There's only two attempts that should be made with --big-typos 3:
1st "best guess":  word1 word2 word3A word4A word5A word6A word7 word8 word9 word10 word11 word12
2nd "best guess": word1 word2 word3A word4A word5A word6B word7 word8 word9 word10 word11 word12

Since there are only 4 uncertain words in this case and word6 has only two possible words, you can let it bruteforce up to 3 mistakes in two separate attempts with word6-A and word6-B.
That's faster than setting it to --big-typos 4.

The work and knowledge you & the others shared is amazing. I have a lot of work to do in the coming days. I will configure my BTCrecover either on the current POP OS or try to get a flavor that can get pyopencl running correctly for GPU acceleration. I will then go over the different Electrum versions while trying to get the V-1.* derivation path to work along with the other possible avenues of approach discussed. Might take me some days but I will update the progress as it rolls out.

Oh, that's pertaining to --language arg that you've included to the command.
I've tested it and apparently, selecting "electrum 1.x" will prohibit you from using certain args like --mnemonic-length as well as --tokenlist.
It'll ask about your "best guess" of the mnemonic instead, then proceed to do its programmed 5-phase bruteforce attack (if used the deafult) to the provided phrase.
(pretty much the same in the old original version of BTCRecover)

I tested BTCRecover v.1.12.0 (seedrecover.py) with an easy 'wrong seed' with 1 wrong word:
v1.x Seed: flutter weak friendship painful shy dirty play forgotten settle double ask season

Best Guess (wrong seed): flutter ask friendship painful shy dirty play forgotten settle double ask season

Yours should be provided with --big-typos 8 arg to limit it to 1 phase with "8" being the number of possible "entirely different seed words".
And that's quite a lot of search space and I don't know how to optimize the bruteforce for electrum 1.x seed in seedrecover though.

Note: this is considering that your mnemonic seed is created in versions 0.34 and above, otherwise you'l have to "ask" someone to modify the seedrecover code to mimic the old bug.

Seems like this isn't nc50lc's first rodeo - https://bitcointalksearch.org/topic/restoring-from-an-electrum-v1-passphrase-5293070

The conversation in this thread is highly similar if not identical to my current developing dilemma. And the fact you just linked the method to possibly find the exact version build I may have used is nothing short of miracle work. I have another set of irons to introduce to the fire. I will create either a virtualbox or just run it on an airgapped linux distro if all i need is an older version of python. That is one approach.


It would be interesting to see if the later versions have backwards compatibility and maybe some improvements in identifying, possibly resolving the compatibility dilemma. Might take me awhile to remember exactly how my version was installed. But at least now I have many more methods of approach.


With BTCrecover I am running my seedtoken off an address.db file. When I tried to use the electrum 1.* option, I got the error saying there was a conflict with 'lang' and I have no idea what that means yet. I will have to make another attempt and copy/paste the exact error. The seedtoken argument worked fine in electrum2 but got no results. I will try to make a run as if it's a basic bitcoin derivation specific to that time and start working with the different versions of Electrum. Hopefully I will get a sense of familiarity immediately when I get the right version.

Once again, thank you all for the great advice, knowledge and confirmed references. Even though it's proving to be far more difficult than expected, just learning more facts, confirming suspicions and ruling out previous beliefs based on evidence, it's a good feeling to know maybe this wasn't all for nothing.

Great! However, if we know how the seed phrase generation worked back then, we could implement a solution to brute force the missing words. The problem is, I am not aware of the way the used to generate the seed phrases from the entropy.

IF (and ONLY IF) it's a BIP39:
The algorithm is:
1. ENT = generate random bits as the entropy (128 bits)
2. B = parse ENT in SHA256
3. CHECK = retrieve the first 4 bits from B
4. FINAL = ENT + CHECK (appended)
5. MNEMONIC = split FINAL into 12 segments of 11 bits each. Convert the 11 bit numbers into decimals. Go to BIP39 wordlist and find in the words in the corresponding decimal places.

So if you wanted to bruteforce it, you could theoretically brute force the missing bits.

Let's move backwards, shall we?

So since you have some of the words, you have something like this:
MNEMONIC = [WORD 1] [WORD 2] [XXXXX] [XXXXX] [XXXXX] [XXXXX] [WORD 7] [WORD 8] [WORD 9] [WORD 10] [WORD 11] [WORD 12]

So, if you find the words in BIP39 word list and get their decimal numbers, then you can convert the decimals to binaries and you will have something like this:
FINAL = [10011001110] [01011111101] [XXXXXXXXXXX] [XXXXXXXXXXX] [XXXXXXXXXXX] [XXXXXXXXXXX] [00000000111] [00110010111] [00011000000] [00000000111] [00111100111] [11000010101]

So, now you can split the FINAL variable into ENT + CHECK (4 bits). It should look like this:
FINAL = ENT + CHECK
FINAL = ENT + [0101]
FINAL = [10011001110] [01011111101]  [XXXXXXXXXXX] [XXXXXXXXXXX] [XXXXXXXXXXX] [XXXXXXXXXXX] [00000000111] [00110010111] [00011000000] [00000000111] [00111100111] [1100001] + [0101]

So, now the difficult part...

1. You must generate random bits for all the places where you have an X and parse the whole ENT through SHA256.
2. Then you must take the first 4 bits of the result and check if they are [0101]. Be careful! You will get more than one sequence that starts with 0101. But you will have a much narrower space to search into.
3. Then for every binary sequence that produces the correct checksum, you must produce the mnemonic again and try it to see if it produces your wallet.


If it's Electrum's seed, I will leave it to someone more knowledgeable than me.

I think they were .exe files. The earliest loadable achieve of Electrum's download site I could load from Wayback machine goes back to May 2013 and version 1.6. It had a Windows executable in .exe format. There is also a zip archive you can download and several third-party releases.

Starting with version 1.7.3, we see similar executables as today. There is the standalone executable, a Windows installer, and a portable version. They are all in .exe format.   
The source I posted from GitHub with the earlier releases are ziped. If you are interested in checking the type of files, you'll have to download some of them to see. My guess is that they were also .exe.

For older versions, he can look for a specific commit in GitHub and browse the repository at that point.

For example; from initial commit onwards: github.com/spesmilo/electrum/commits/master?after=bdbd59300fbd35b01605e66145458e5f396108e8+14035
By clicking "<>" (Browse repository at this point), you can get to the source code at that time to try to run it with old version of Python. (only useful if the seed is complete)
For example; v0.31: github.com/spesmilo/electrum/tree/eaedbae083529fc12044ecfb5b0b613c32c70691

The good news is, Electrum keeps backward compatibility from v0.34 to the latest, the old mnemonic will be detected as "old" and can be restored in the latest version without issues.
The bad news is, older versions than those have a key derivation bug that had to be patched which causes the private keys derived in those versions different than the keys derived in the newer versions.

In case it was v0.34~v1.9.8, BTCRecover's seedrecover can still be used with the right options when prompted: specifically seed type: "Electrum 1.x".
But before doing it, double-check the words if those are included to the "old_mnemonic" in my reply above.
Otherwise, it's newer that you thought or from a different wallet entirely.

Took much head banging into walls, but I think we might be onto something here. Thanx to you and the others for giving me good council and now we have a whole new point of view. I'd rather have the facts albeit more difficult.

It might be a benefit that my suspected version of Electrum doesn't connect to any servers anymore as outmoded software are kinda like rare antiques. Unique in their design, and I made my mnemonic offline anyway.

Optimistically, I might be able to dig up the installation method on the disk that was used back then. Was Electrum installed on Windows using EXE or something else? Or an even more specific question, what derivation path did Electrum use when it very first implemented the 2048 wordlist if BIP 39 wasn't even a thing?

The words that I know are still the same. I was using the previous approach on BTCrecover to make sure there were no mistakes. The latest attempts using an updated seedtoken.txt looked like this

^1^knownwordlocked
^2^knownwordlocked
^7^knownwordlocked
^8^knownwordlocked
^9^knownwordlocked
^10^knownwordlocked
^11^knownwordlocked
^12^knownwordlocked
5 words including the known word that is position 3 or 4
5 words including the known word that is position 3 or 4
5 words NOT including the known word that is position 3 or 4
2 words that are position 6

But, if the notion of what we have been nudging at is true, that the version of Electrum I used had it's own way of using the same 2048 words but NOT implementing the BIP 39 standard, then not only do I have a unique situation, I also have a very difficult path to get the mnemonic correct.

I was using anything from Electrum version 0.29 to 0.46. Maybe there is some backwards compatibility in those versions. I will have to research more

It seems to me that the seed phrase perhaps isn't a BIP39 but a prior version of electrum's seed phrase.

I think Electrum started using versioning in seed phrases since version 2.0 ^[1]. So, if this is correct, then OP perhaps owns a seed phrase that was produced without the current versioning system, so OP must try and find the old code to make it work. Am I right?

[1] https://electrum.readthedocs.io/en/latest/seedphrase.html

That only goes as far back as to version 1.8 from 2015. Electrum's GitHub releases date back to 0.56 from 2012 (https://github.com/spesmilo/electrum/tags?after=0.57a). I am not sure if it's possible to find versions of the software that are older than that. I think anything older than 3.3.4 can't connect to servers anyway.

OP I saw your initial post. Are you sure the phrase uses the BIP39 standard?

Can you also give us an update of the words you know (or perhaps the one you have found during these 2 years) ?

Let me guide your answer a little bit:

word 1 - known
word 2 - known
words 3, 4, 5, 6 - you only know one word for positions 3 - 6 but don't know it's position, so you basically have 3 missing words in these positions?
words 7, 8 - you know the words but don't know the positions, so you don't have any missing words, but only ther order missing?
words 9, 10 - you know the words but don't know the positions, so you don't have any missing words, but only ther order missing?
word 11 - known
word 12 - known


Here are the older versions that are available for download: https://download.electrum.org/

Unfortunately 2012 seems too long ago...

It checks-out since the old version had both client and server which can use a modified bitcoin node to connect to.