This is a tool that might (emphasis on might) give a more detailed error message on why your password isn't working. It simply displays your Electrum seed if the password is correct, and if not it prints one or more error messages.

If you choose to run it, post the results back here and I'll let you know what I think (it's a Python script which I wrote).

(Obviously, if it reports back any actual seed information, don't post it!)

I've written MultiBit wallet manipulation tools in the past (in Python), so it shouldn't be too difficult to take one of those tools and change it to simply load and decrypt a wallet and print out a bunch of debugging info in the event of a failure. That may help (or maybe not...) in getting to the bottom of this.

Unfortunately, it requires installing some Python libraries, and doing so is very difficult in OS X (although for the specific libraries that are needed, it's usually easy under Windows or Linux).

tonyClifton13, I believe you're on OS X, correct? If you know someone you can trust to manipulate your wallet file and password who is on Windows or Linux, or if you have access to a Windows or Linux box yourself, let me know and I'll write such a tool when time permits. (If not, it doesn't make sense for me to go through the effort if all you've got access to is OS X though...)

If I understand you correctly, you're saying that more sophisticated malware with keylogging isn't slowed down at all by good key stretching, and such sophisticated malware has become fairly commonplace. I couldn't agree more...

Good key stretching is still important if you ever intend to keep wallet backups stored anywhere online (e.g. a backup services), and it can help protect against stupid malware (which still exists), but I agree it does nothing against sophisticated malware. In short: good password key stretching can sometimes help, and there's no reason for any wallet software to use weak key stretching (except of course that it requires development effort, and developers have limited time and long lists of new features to be added).

As I'm sure you've guessed, BC.i requires each browser/OS combination to be email-authenticated (just once, unless you nuke your cookies regularly) for all accounts that have a registered email address, even those which haven't enabled 2FA. This is a fairly recent change (a few weeks ago).

If you don't have a backup, and can't locate a browser with a cached copy, your only choice is to open a support request as others have already pointed out....

I can try, hopefully the language difference won't be a problem...

Please describe everything you remember about your password. Creating a bunch of example passwords will also help. PM me if you'd rather not post the information publicly.

Can Google translate the Quick Start section (just #1 and #5) and the Installation section of the Tutorial well enough for you to understand and to follow it?

Did you have 2FA enabled? If you didn't, there's some chance your wallet is still cached in your browser (unless you've logged into it successfully in the last few weeks -- BC.i disabled caching a few weeks ago).

To find out if you do have it cached, visit the login page (don't try to log in), press F12 to open the debugging tools, choose the Console tab at the top of the debugging tools, and in the console window type (depending on the browser, the console field where you can type things may be at the bottom of the console window):


If you get something back in the console besides "undefined", copy the entire thing into a text file for safe keeping in case BC.i support can't/won't restore your access.

Maybe I can... but no promises.

I wrote btcrecover exactly for this purpose, but I've found that the biggest challenge to password recovery sometimes isn't technical, but instead it's the language difference.

There's a Tutorial here, but it's in English which I'm sure will make it difficult to understand (and I don't speak French, sorry).

If you can provide more specific details on the password you're trying to find (PM me if the password details shouldn't be public), I'll try to help out (but it would still be up to you to download btcrecover and run it on your own computer)....

To help illustrate some of the excellent posts above, I've made a quick-and-dirty estimate of how often you might expect to find such seemingly common phrases in an Electrum seed. Intuitively, it may seem that it should only happen rarely if the seed is truly random, but in fact it's not all that uncommon.

I downloaded the 1,000,000 most common 2-grams (phrases of 2 words) from BYU's Corpus of Contemporary American English. There were 61,721 common 2-grams on this list where both words were from Electrum's list of 1,626 possible seed words. So:

Let w be the count of all possible 2-grams of words taken from Electrum's word list.
w = 1626²

Out of these w possible permutations, 61,721 are on the downloaded list of common 2-grams.

Let S be the event where a single pair of randomly chosen words is in the common list.
P(S)  = 61721 / w ≈ 2.3%  (probability a single random pair is common)
P(S') = 1 - P(S)    ≈ 97%   (probability a single random pair is not common)

Let T be the event where all consecutive pairs of words in a list of 12 words are not common.
P(T)   = P(S'₁ ∩ S'₂ ∩ ... ∩ S'₁₁)
P(T)   = P(S')¹¹  ≈ 77%  (probability that all 11 consecutive pairs of an Electrum 12-word seed are not common)
P(T')  = 1 - P(T) ≈ 23%  (probability that at least one of the 11 pairs of an Electrum seed is common)

So there's an almost 1 in 4 chance that a randomly generated Electrum seed will have a pair of adjacent words on the 1,000,000 most common list. Since that list isn't all that big (for comparison, it includes "green screen" but not "velvel cage" nor "nerd paradise"), it's probably even more likely that a random seed contains uncommon but grammatically correct (and sensical) pairs of words like "nerd paradise".

Although this really isn't related to OP's question, it may be worth mentioning anyways. One Electrum weakness (compared to Bitcoin Core) is its poor key stretching when password-protecting the wallet file (against brute-force attacks). Bitcoin Core aims to require about 0.1 seconds of CPU time per password attempt which results in around 100,000 SHA-512 iterations, whereas Electrum uses just 2 SHA-256's.

This makes brute-forcing the password of an Electrum wallet much easier, and therefore requires the use of a stronger password (vs. Bitcoin Core) to achieve the same level of brute-force resistance.

I went ahead and wrote a python script which can extract the seed from either a backup file or from the raw wallet file (which you can only get to if your phone is rooted). Feel free to give it a try, instructions and download links are at GitHub: https://github.com/gurnec/decrypt_bitcoinj_seed. You'll of course need your backup password (if it's a wallet backup file) and your PIN, if any.

I've verified that the seed I get from the script can be used to generate the same sequence of addresses/keys as are in the app (I just went here and plugged in my seed -- obviously if you choose to do something similar with anything but a test seed, you should use an offline copy of that page).

Technology-wise, they check off a number of boxes which Blockchain.info misses.

I don't think they have any black marks in their history (BC.i has a number of them), but they're also much younger than BC.i. Short of an independent audit... it's awfully hard to say.

Having said that, they are the mobile wall that I've chosen to use, so I at least think that they're a safe option.

If you do go with them, please be certain to:

• Write down your "mnemonic" as soon as you can. It's your backup, your password (PIN) recovery, and it's the only way you can log into your wallet from new devices. Don't save it to your PC (or learn how to use strong encryption if you must).
• Don't be afraid of using the PIN quick login option, it may seem like weak security but it's actually quite strong (and convenient). (If you enter your PIN in wrong just 3 times, it becomes useless and you'll need your mnemonic which you wrote down earlier.)
• Enable email notification for both inbound and outbound notifications. Each email notification contains a special recovery file which you'll need should GreenAddress ever disappear from the net (heaven forbid, of course).
• If you intend on using GreenAddress from a desktop, enable two-factor authentication. For a mobile, I'd be less concerned about two-factor.

That's my 2 satoshis...

There are two ways of creating a bitcoin transaction. The (generally considered older) way requires a very secure RNG (an unpredictable random number generator), and for this reason it's considered a bit more risky. This is the method that Blockchain.info uses, and a recent change inadvertently broke their RNG for a little while.

The other way is what tryexcept mentioned -- it doesn't need any RNG for creating a transaction, and is generally considered safer (although since it's also newer, not every wallet uses it). It's also much easier to write tests for, if the developers use an automated testing tool to make sure that no bugs creep in.

(There are other ways too, but they're worse than the methods above, so they're rarely used.)

(You do still need a good RNG when you first create your wallet though.)

That's odd... when I try this, it works fine for me. Is this exactly what you're running?


You are on Windows, correct? Are you running it from an elevated ("Run as administrator") command prompt? Are you running the same version as I am (downloaded Sept 8th or later from https://github.com/jackjack-jj/pywallet)?

Also, is your hard drive less than 120 gigabytes in size?

It's just a directory name where a wallet.dat file with the recovered keys will be created. You shouldn't choose a directory that's on the same drive that your trying to recover keys from. If you only have one drive, you could plug a USB stick in and use it as the outputdir (e.g. "--recov_outputdir e:\" or similar).

(edited to add: also you may want to move this thread over to the Tech Support forum... the "move thread" link is towards the bottom left)

That's true, but it's not the most limiting factor.

The effective strength of ECDSA is roughly half the private key length, so 128 bits for secp256k1 used by Bitcoin. 2^128 is still a staggeringly big number, so it's probably nothing to worry about anytime soon.

128 bit seeds are easier to write down (BIP39 style), and 256 bit seeds probably aren't much stronger. This all assumes those 128 bits are actually generated from good entropy -- 256 bits of mediocre entropy are definitely better than 128 bits of mediocre entropy (and probably would make a practical difference).

Incidentally, I keep inserting "probably" everywhere because I'm not an expert, so take all this with a grain of salt....

Positive error codes returned by Berkeley DB library are C errno codes, and error 1 is EPERM: Operation Not Permitted. Try checking the file and directory permissions on the machine that's having trouble to ensure whichever user is running bitcoin-qt has read/write permissions to wallet.dat.

If it's just your ID you're missing, and you still know your password, you're probably OK.

Open a support request here: https://blockchain.info/support-desk

Be sure to include as much information as you can -- your previous wallet IDs, your IP address, your recent transactions, your balance (I wouldn't include your password but do mention that you still have it).

Good luck....

Blockchain.info is a strictly non-BIP32 wallet (an older method of creating addresses which requires frequent backups), and with the exception of vouchers^*, GreenAddress.it is a strictly BIP32 (newer backup-friendly address creation) + multisig (much better malware protection vs. non-multisig wallets after enabling two-factor auth) wallet. There is no way to import/export between the two of them. If you'd like to switch from one to the other, you'll have to send btc from one to the other and stop using any old addresses (or continue to use both).

* Although I think you could technically create a voucher at GreenAddress and import its private keys into Blockchain.info, I have no idea why anyone would ever want to do this....

Try this to get the same list of addresses that's displayed in the GUI (they all have a reserved:0 in the wallet dumpfile):



The other addresses with keys are a result of change and the key pool.

findftp and aliveonearth:

This is certainly the ugliest python one-liner I've ever written... but here it is anyways


1. Copy and paste the one-liner into a terminal (command prompt). In Windows, you'll probably need to add "C:\Python27\" to the beginning.
2. After pressing Enter, it will ask you for your wallet ID.
3. If you have an email address associated with your account, it will display a (very long) error message which starts with this:
    You'll need to follow the directions in the email you receive from BC.i and click on the "Approve" button. Only after doing so, press the Enter key (at the "Retry..." prompt in the terminal window).
4. If you have two-factor authorization enabled on your account, you'll receive a prompt asking for your 2FA code. (If it's an email or an SMS 2FA, you should receive it from BC.i shortly).
5. Once the above is complete, a wallet.aes.json file will be created in the current directory (the script will fail with an error message at step 2 if such a file already exists).

Let me know if this works (or doesn't)!