For starters, Armory doesn't currently support any form of mnemonic....

That aside, there is a standard (called BIP39), although Electrum 1.x was created before BIP39 was envisioned. Electrum 2.x (and many other wallets I hope) will be interoperable and support BIP39 in the not-very-distant future.

I don't care for the idea of completely restricting a newbie's ability to send PMs either, but a very visible warning is definitely something I'd support.


Yes, at least in my limited case. People don't often like discussing their password details publicly (for the purposes of attempting to recover a wallet with a forgotten password; see btcrecover). I'd be lying if I said I've received tons of such PMs (I've only received a handful), but at the same time I'm sure that newbies who have contacted me are appreciative that they can.

(Full disclosure: although btcrecover is open source, I've rarely (exactly once) agreed to a paid password recovery at the unsolicited request of another.)

There are some brute-forcing tools out there available for Electrum (assuming you have a decent idea of what your password is).

I rather like btcrecover (tutorial is here). It's free and open source; of course, being the dev of that one I'm a just a little bit biased...

You can also find a tool towards the end of this thread for Electrum: https://bitcointalk.org/index.php?topic=85495

There are also paid services that can help you out, although I'm unsure of which ones support Electrum. Here are some starting points for the paid services:

• https://bitcointalk.org/index.php?topic=85495.0
• http://www.walletrecoveryservices.com/
• https://bitcointalk.org/index.php?topic=717334.0

If you have any questions about btcrecover, please just let me know.

Good luck!

There is an open-source tool which can extract the mnemonic (seed words) from a Bitcoin Wallet for Android 4.x backup file. The mnemonic is a standard BIP39 mnemonic using the English word list. Although there aren't a whole lot of wallets which directly support the importing of a BIP39 mnemonic yet, that's likely to change in the upcoming months.

You're really not giving the core devs enough credit IMO by claiming their only significant contribution (even if filtered to "mainstream" promotion) is the Bitcoin Core client itself. Where would Bitcoin as a whole be without BIP32, BIP7x, mutlisig, P2SH, etc. despite that fact that some of those are only partially (if at all) implemented in Bitcoin Core (not to mention contributions to the bitcoin.org website as well)?

Charging for the service hopefully decrease the likelihood that they will go out of business, but ultimately it's a judgement call: is the added protection against malware (although not bulletproof) worth the extra transaction fee and the inconvenience should they go offline? I rather think so (although the fee is a bit high for my taste), but to each their own.

You mean this command...?
wallet.change_gap_limit(200)

grendel25,

To put it in a less technical way, any 2FA-style device has to provide a way to prove to someone else that it is in the operator's control. This is done by the 2FA device providing a code.

For Google Auth, YubiKey, and the like, both the device and the someone else (a centralized online service provider) have a common "shared secret", and this secret can be used to generate short codes that are just a few digits long. The shared secret can't be stored in the blockchain because then anyone could generate the codes.

Hardware wallets (and Bitcoin in general) use public-key cryptography and can use a publicly-viewable blockchain to prove that the codes they generate (called signatures) are valid. Unfortunately, the codes that they generate as proof are 155 digits long (or 88 if encoded in Base58), so it wouldn't be very practical to ask a user to type these codes in. That's (one reason) why they transfer these codes via USB.

The point is that you can't have the advantages of both: you can't have a 2FA device which uses public-key cryptography and would be publicly verifiable via the blockchain which also provides short codes. This means we're stuck with either centralization, or hardware wallets which need a digitial connection (USB today, possibly Bluetooth or audio in the future?).

Incidentally, Electrum 2.x does plan on implementing both styles of 2FA, with Trezor and HW.1 on the hardware wallet side, and with TrustedCoin on the centralized short-code side.

Just for future reference, you can use change_gap_limit() instead which doesn't require a restart, e.g.:

You're in a tough situation, pretty much your only option is to attempt to a brute-forcing solution.

There are free (but not necessarily easy) options, and there are paid options. To make matters more complicated, you'll need to decide if you want to try to brute-force your wallet password or your seed. Here's the break-down, as far as I'm aware.

Free options:
  Brute-forcing an Electrum seed: see this thread.
  Brute-forcing an Electrum wallet password: see btcrecover (tutorial is here) or this thread.

Paid options:
  Brute-forcing a seed: ??
  Brute-forcing a wallet password (I don't know which if any of these support Electrum):
    - https://bitcointalk.org/index.php?topic=85495.0
    - http://www.walletrecoveryservices.com/
    - https://bitcointalk.org/index.php?topic=717334.0

FYI I can help out with the btcrecover option if you choose to try it. Good luck....

I know I'm not exactly answering your question (sorry, I don't really know ruby either), but if you'd like to try btcrecover (if someone with ruby experience doesn't respond), I can help you with that.

You'd basically need to download it (from the "download zip" button at the page linked above), and then take what's below and save it to a text file named "btcrecover-tokens-auto.txt" in the same directory as the Python script, and then follow the instructions under Quick Start in the Tutorial.


Let me know if you have any questions...

You do need to be more careful when it comes to storing Electrum wallets online compared to many other wallets.

As others have already noted, nearly all wallets are open to brute force attacks. However, given a strong-enough password, any wallet can be safely stored online. The big problem is in determining whether or not your password is strong enough to resist brute forcing attacks, and there's no easy way to be sure.

This javascript site is the best I know of (thanks to Newar) at estimating password strength: https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.html. There's an accompanying article discussing its method's strengths and weaknesses here (spoiler: it might be very good, but it's definitely not perfect): https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-strength-estimation/.

What's different about Electrum is that it doesn't use any key stretching, so if you don't use a very strong password, you're much more vulnerable to brute force attacks than some other wallets such as Bitcoin Core or Armory. Here's a quick overview of how many cryptographic operations must be done to check a single password for these two wallet formats:

Electrum: 2 SHA-256's (each a single block long) and 1 block of AES-256 decryption
Bitcoin Core: approximately 100,000 SHA-512's (each a single block long) and 2x blocks of AES-256 decryptions

TL;DR: use a strong-enough password, and you'll probably be safe from brute force attacks, but it's really hard to know what "strong-enough" means.

I think the question is did you run the second tool created by jonald_fyookball which assumes your seed is off by one word, and tries all possible seed combinations starting with that assumption (and takes a few hours to complete).

To elaborate a bit, if you follow the advice next to the "News" alert at the top of every bitcointalk.org page, you don't need 0.9.4. It's a minor update whose main reason for existence is to work around the OpenSSL change mentioned in the News alert (plus a few other pretty minor bug fixes).

There was an issue opened on the bitcoin.org repo (to update the increasingly impressive developer docs) stating that 15-of-15 P2SH transactions have been standard since 0.9.0, and it included this link to the bitcoin repo as evidence of a 1650 maximum byte scriptSig: https://github.com/bitcoin/bitcoin/blob/0.9/src/main.cpp#L543

So it appears that they're already standard unless something else is in the way (in which case I'm sure the bitcoin.org folk would want to know so they can correct the developer docs)...

Do you have any older backups of your wallet file?

Likewise on Windows -- if you lock your account either explicitly (shortcut: windows-L) or implicitly (starting a Remote Desktop session with user #2 while user #1 is logged in), all programs will remain running in the background (except Win8 Metro-style apps, but that's irrelevant). I think shorena's option of running a single Bitcoin Core instance w/o a wallet and then configuring mSIGNA or Multibit clients to connect to localhost is probably the best option.

That would seem to indicate that you either no longer have the correct password for the wallet file, or that multiple bytes in the wallet file have changed. Between these two options, the former seems more likely....

If only a single byte were corrupted, then at least the PKCS7 padding would be valid or the count of valid hex-encoded digits would be 16 or greater (because at least one of the three 16-byte AES blocks would still be decrypted successfully).

I can think of three things you might want to try:

1. Have you tried to run jonald_fyookball's (excellent) tool yet with a higher numberofreceivingaddresses and numberofchangeaddresses to see if any of the generated addresses are yours (if any of them exist on the block chain)?

2. Attempt to brute-force your wallet password with either an open source bitcoin password recovery tool or using one of the paid services in the Services section of the forum.

3. Attempt to brute-force your mnemonic on the assumption that one of the words is wrong or swapped with an adjacent word (although I'm not aware of any tools or services that exists to do this).

What are all of the error messages it produces?

I've no idea why that is....

Sorry about that; there was a bug related to ASCII/Unicode conversion, now fixed. Could you download a new copy and try it again?