As o_e_l_e_o has mentioned, it adds another layer to the "physical" security of your seed backup... If someone were to get hold of your 12/24 word seed, they might find a small amount of coins in the "base" account, but would be unable to access anything that was protected by a passphrase (assuming that your passphrase is not co-located with the seed backup... which obviously it should not be)

Additionally, attempting to bruteforce passphrases is actually quite time consuming because of the methods used (ie. every passphrase generates a "valid" wallet, so you need to go through many "costly" derivations to derive and then check addresses)

And... If you happen to be using a Trezor ONE, it's pretty much required to prevent total loss in the event that the device is physically compromised. ie. it is stolen or lost.

The problem is twofold.

#1. You appear to be using an old outdated version of Armory (0.96). I assume you got it from here: www. bitcoinarmory.com

DO NOT use this website... it is old, outdated and no longer maintained. The current website that you should use is: https://btcarmory.com/


#2. You are using Bitcoin Core in Pruned mode. Armory requires the full and complete blockchain on disk so that it can scan the blockchain history properly. You need to disable pruned mode in the settings and then let Bitcoin Core resync.

---

I would recommend that you upgrade to v0.96.5 that is available here: https://btcarmory.com/0.96.5-release/

It works on Windows 10 with Bitcoin 0.21.1... however, as noted above, you can NOT use Bitcoin Core in pruned mode if you want to use Armory.


So, at this stage, your options are:

1. Update to Armory 0.96.5, disabled pruning in Bitcoin Core, let Bitcoin Core fully sync (requires ~400 gigs free harddrive space) and then run Armory.

or

2. Move to an SPV wallet like Electrum.


If you have already sent funds to an Armory address, and just want to move to another wallet, you can follow my guide here on how to export your private keys from Armory: https://bitcointalk.org/index.php?topic=4746784.msg43255691#msg43255691

Do you know if that is device specific? or is it the "default" derivation path for Tron?

I recall many years ago Ledger had some non-standard path for ETH which caused some issues when trying to use the device with MEW etc. They had a specific "Ledger" option when trying to open your wallet.

You must be thinking of another wallet... Mycelium is BIP39 only, it won't accept an Electrum seed.

The only ones that I know of are Sparrow and Blue Wallet. I suspect you're thinking of Blue wallet, as it's for mobile devices... whereas Sparrow is a desktop wallet.

It's a long shot, given the old age of this OP... but are you still looking for help with recovering your coins from Multibit?

What is the exact format of the 2 sets of random numbers? How many characters long are they? Are they ONLY numbers? or does it contain letters as well? What is the first letter/number of each code?

Does it look like the code in this screenshot:


ie. the "HFZIZRDSSJ7G5WYB" code?

If so, that is the Google Authenticator "secret key", and you can recover your 2FA by using that secret key with any Google Authenticator compatible app (like Aegis, or Authenticator Plus etc)


NOTE: DO NOT POST THE ACTUAL CODES HERE! We just need to get an idea of what these "codes" actually are.


I suspect you have copied the location of where your wallet file is stored on the PC that is shown during Electrum 2FA wallet creation:


it's not very useful unless you still have access to that particular computer... and still have access to your 2FA device

The portable version is slightly different in that it doesn't store the application/wallet data in the "%AppData%/Electrum" location... instead, it will create a folder called "electrum_data" in the same location as the portable.exe and store all the application and wallet data there.

This allows you to use/run Electrum on say a USB thumb drive without leaving any trace on the main system drive etc. (Nothing listed in Add/Remove programs, no entries in start menu etc).

By default, the signature file (ie. the .asc file) needs to be: name_of_the_binary_file_being_checked.asc

That way, when you attempt to verify it, it will automatically, remove the .asc and then look for "name_of_the_binary_file_being_checked". ie. if your file is called "electrum-4.1.4.dmg", then the .asc file should be: "electrum-4.1.4.dmg.asc"

If it can't find that file, the process will generally error out.


However, for whatever reason, the Electrum peeps have decided to also include the name of person whose key was used to sign the file... ie. "name_of_the_binary_file_being_check.ThomasV.asc"

or, in this specific instance, "electrum-4.1.4.dmg.ThomasV.asc"

This causes problems because when the system then removes the .asc and goes looking for "electrum-4.1.4.dmg.ThomasV", it obviously doesn't exist... and it will not be able to automatically complete the verification.

---

TLDR: the .asc filename should be identical to the original binary with ONLY the .asc extension added for "automatic" verification to work.

Correct, the first part of the modification should be all that is required... this is the bit that basically bypasses/ignores the checksum (similar to what Electrum does)... You just force it to return true, rather than calculate the checksum and see if it matches etc.

You don't want the second part, the change from "mnemonic"+passphrase --> "electrum"+passphrase as that will break the BIP39 generation...

I've just tested this, and it seems to work.

Electrum seed:

OG Ian Coleman tool, checksum fails:



Modified Ian Coleman tool set to ignore checksum:



Generated addresses:



Addresses in Electrum using BIP39 option and "Legacy" + m/44'/0'/0' path:



FYI, the line of code that needs to be modified was on Line# 28526 on the current version of the Ian Coleman tool:




No. Because that 2nd tool includes the "electrum"+passphrase modification... so any seed that it generates will NOT be BIP39 compliant. The thing you need to realise is that even if you don't explicitly use a BIP39 passphrase (or the "seed extenstion phrase" in Electrum)... there is a default one that is used... in BIP39 it is the word "mnemonic"... in electrum it is the word "electrum". So, even if you leave it blank, the 2 systems will never generate the same seed from the same 12/24 words.


Not quite sure how that factors into things? Your wallet was an old Legacy wallet... it'll most likely be in the m/44'/0'/0' derivation path... they extra "script_type" value is only a factor when creating newer SegWit based wallets.

That is possibly one of the worst ways you could attempt to bruteforce a BIP39 passphrase.


Correct... you're probably thinking of the guy who lost the PIN to his Trezor... and the wait time was growing exponentially: https://www.wired.com/story/i-forgot-my-pin-an-epic-tale-of-losing-dollar30000-in-bitcoin/


Device PINs are often set to wipe the device (ie. Ledger), increase the wait time (Trezor, older Coldcards) or even brick the device completely (new Coldcards).

However, the BIP39 passphrase is a completely different mechanism... and there is no such thing as an "invalid" BIP39 passphrase, as anything you enter will generate a valid seed, so it's impossible for a device to detect if you've used the wrong passphrase.

I didn't say you did... I was merely pointing out that further posts in that reddit thread would indicate that the user simply received 2 "OG" devices.


Probably the same way my wife once received an airfryer, that she never ordered, along with her actual order of discount comestics. People make mistakes.

Hell, I've received the "same" order twice before from various companies... granted it wasn't from Ledger, but it's certainly not unheard of.

Ahhhh OK, yeah that would make sense... I guess someone thought you were asking for help trying to recover coins from an old wallet, as opposed to just wanting to have a generalised discussion

No drama... if the mods think it's best here, then here it shall stay.

---

As for your original topic, I have a few stories from the 2017 "gold rush" Nothing super exciting though... just helping folks recover wallets from bad backups of seeds (ie. missing words) or getting fork coins out of multisig wallets etc. most of which is documented in various threads about this forum

It isn't as nearly as complicated or scary as they are making out... if you manage to recover the wallet.dat, you really just need to install Bitcoin Core, put a copy of your old wallet.dat in the data directory, then run Bitcoin Core and let it sync. Then you'll see the transaction history and current balance of the wallet file... and you'll be able to decide what you next move is from that point.

Yes, things will be more complicated if the wallet file is corrupted... but it sounds like the damage was to the drive controller and not to the physical platters etc, so theoretically the data should still be "OK" (assuming there hasn't been any 'bit rot').

---

Yes, any thing is "possible"... it's just a matter of what is "probable".

To be honest, the vast majority of these "I mined/bought BTC in 20XX, help!"-type threads, turn out to be instances where they did buy BTC, but already spent it... or they are trying to recover data from devices used 6-7+ years ago and formatted/wiped etc... or they're trying to access online services that no longer exist...

Then you get the wallet.dat's from altcoins like LTC or DOGE etc. Or, you get "1 post Andy's" who start a thread, post some vague description of their situation and then disappear into the ether.

So, I'm not really surprised that a number of users here are a bit cynical when these types of threads pop up.

Honestly... not likely to be a derivation path issue then.


Ahhhh that would require something slightly different I believe... as it seems you're trying to get the "BIP39 version" of an Electrum seed.

Generally speaking... an Electrum generated seed will not be a valid BIP39 seed (there are some relatively rare exceptions). So, if you click the "BIP39 seed" and type in an Electrum seed, it will likely show "checksum: failed". Electrum will allow you to go ahead and use it anyway if you really want...

But, to the best of my knowledge, there is no way to replicate this behaviour with the Ian Coleman tool (or the tool I posted). However, it should theoretically be possible by simply modifying the Ian Coleman tool to ignore the checksum calculation.

I'll have a look into it over the weekend and see what I can come up with (if someone else doesn't beat me to it)

It doesn't appear to be true... The photo of the backside of the users PCB looks clean:



versus one of the tampered ones with extra component and soldering etc:




And they got it in the "normal" Ledger packaging... not the (very convincing) "fake" packaging and no associated letter etc.

Seed extension phrases are a good idea... but you do need to be aware of the potential pitfalls.

So, one very important thing to note... if you're going to use a second (randomly generated) 12 word seed phrase as your "seed extension"... is that the seed extension phrase has NO checksum detection.

This means you can type literally anything you like in the seed extension box and Electrum will quite happily use it and generate a wallet. A small typo and you get a completely different wallet.

So:

will generate a different wallet from:

But the software will not be able to tell you that you've made a mistake, even though technically the 12 word seed has a checksum included, it's effectively useless...

So, you will need to be very very careful when both recording and subsequently entering your seed extension phrase else you might end up with a "bad backup" and run into issues in the future when trying to recover your wallet.

It's possible to work around that restriction based on the configuration of the ElectrumX server... it's basically a "protection" to prevent servers from being DDoS'd (accidentally?) by requesting huge amounts of data. Refer: https://electrumx-spesmilo.readthedocs.io/en/latest/environment.html#resource-usage-limits

As for only returning partial data... I don't think that is a very wise decision. You should return "all" or "none"... giving a partial result could result in all sorts of issues and would likely result in the end user getting very confused.

Or... if the return set is so massive because a particular address has hundreds/thousands of addresses and it would cause issues, the server should really generate a "paged" result set and allow the client to request specific pages or subsets in smaller blocks.

For the record... the various CRCs I get from 4.1.4 dmg are:

and the contents of electrum-4.1.4.dmg.ThomasV.asc is:

These files seems to verify OK:



NOTE: I had to rename electrum-4.1.4.dmg.ThomasV.asc to electrum-4.1.4.dmg.asc so that Kleopatra would work properly

That is indeed correct... mine was basically identical to Ian Coleman's with the checksum stuff effectively commented out (or forced to return "true")... and the BIP39 passphrase changed from "passphrase" to "electrum".

The FarCanary version was slightly more robust and actually implemented the Electrum checksum code.


I had originally given it a "relatively thorough" check and couldn't see anything out of the ordinary... but it certainly wasn't a line by line check, so I wouldn't stake my life savings on it.

Yeah... the expiry time seems to have a lot more use for lightning transactions that the more traditional "on-chain" transactions. A lot of the lightning wallets that I have experimented with require "invoices" to be created to receive a payment and most of them "require" some sort of expiry time.

On a side note, I'm still not completely sold on the addition of the lightning functionality into Electrum. I can see that it would be useful to some (and I know the BIP70 stuff was already there)... I'm just concerned it might be over-reaching and possibly overcomplicating things.