Probably true if it's a human generating the key, but what if it's a website application that's generating the key? I could easily see a case where the key is generated, persisted only to the disk cache, then a page with the address is sent to some user, and then a crash occurs...

Of course servers shouldn't be generating private keys at all, they should either be using a cache of public addresses or generating addresses deterministically from a master public key. 

I don't know what the very best is, but they're definitely not all the same. I somewhat answered this over here: https://bitcointalk.org/index.php?topic=704771.msg7975168#msg7975168.

What are your concerns / priorities?

Strong random number generation? For this, my first choice would be Armory. In addition to the OS's random number pool (either /dev/random or CryptGenRandom), it also mixes in:
It's also a deterministic wallet if that matters to you.

Ease of use? For that I'd download a copy of https://bitcoinpaperwallet.com/ (download link is in the lower right of the live demo). It's not quite as thorough as Armory, but it does use window.crypto.getRandomValues which should in theory use the OS's random number pool, and it also uses mouse and keypress events. It's easy to use for paper wallet generation, and quite pretty too.

https://www.bitaddress.org/, while not quite as pretty, uses the same random number techniques as bitcoinpaperwallet (actually I think bitaddress was first, and bitcoinpaperwallet is based in part on bitaddress). It's probably the way to go if you want an easy method of generating a lot of paper wallets all at once.

Edited to add: both bitcoinpaperwallet and bitaddress support brain wallets, and bitcoinpaperwallet gives fairly decent advice on how to use dice or an extremely-well-shuffled deck of cards to generate the random keys, although there's better advice over in this thread.

This error is DB_RUNRECOVERY.

Assuming a simple restart doesn't fix it, there are two things I'd try.

If you're on Linux, you probably have easy access to the Berkeley DB tools. On Debian/Ubuntu, they can be installed with "sudo apt-get install db-util". After closing bitcoind and making a backup of the wallet.dat file, try running "db_recover -c wallet.dat" from inside the .bitcoin directory. If that succeeds, you're probably all set.

If you're not on Linux, or if the above doesn't succeed, try running "bitcoind -salvagewallet" (Bitcoin will make a backup on its own before trying to run the salvage routine).

If this also doesn't work and you're on Linux, look over here for another option.

If you're still having problems, pywallet is probably your next option, however it's got its own problems (that I mention in the post above).

Good luck!

I suspect you already have a good feel for the basic differences between wallet choices, but if not, this link might help: http://gurnec.github.io/btc-wallet-comparison/

I have to disagree with coinsolidation... that message doesn't apply to the database version, but rather the environment version which is something else entirely in the complicated Berekeley DB world.... The Bitcoin client typically creates the environment on startup, and deletes it before exiting (except for really old versions of Bitcoin).

pywallet does not delete the environment before exiting, so I suspect that the warning message above is the result of running pywallet, and then running Bitcoin afterwards. In any case, I'm fairly sure it shouldn't cause any problems, and that it's just a warning.

Since you're on linux, you could use the Berkeley DB command line utilities to see if they can do any better. In theory, they try to do the same thing as -salvagewallet, but they're more up to date versions than the 4.8 that ships with Bitcoin, so maybe this will help.

On Debian/Ubuntu, they can be installed with "sudo apt-get install db-util". Then try this:


If the first command produces a bunch of output, run the second one to create a newwallet.dat. If the first command doesn't produce output, try it again with a capital -R instead of the lowercase.

If all this still doesn't work, I could come up with some instructions for using pywallet's recovery methods. It would be my last choice though... pywallet doesn't recover the address book, and it's encryption facilities are fairly well broken, so you'd have to use them to create an unencrypted wallet and then deal with the consequences...

Here's the full error message, which python truncates to just the last line:

Theoretically this should only happen if the wallet.dat file is copied out of the data directory while Bitcoin is still running or immediately following a crash.

If this is the only problem, running bitcoin-qt with the -salvagewallet option (with the wallet.dat to recover in the data dir) should be able to recover most if not all of the wallet.

Agreed... not that I'm claiming I'm knowledgeable enough to help, but I'll bet someone here is.


This might be harder than you think, if you really want 100% foolproofness. Printers can run out of ink, hardware RAID can lie to the OS and claim that data has been written if it thinks its backup batteries are sufficient... there are a lot of what-ifs if you don't go into more details.

What I'm trying to say is that even if there is a client that makes the appropriate sync call, things can still go wrong. At some point, it becomes more about risk management than about 100% guarantees...

Also, for what it's worth, I can say that neither Bitcoin Core nor Armory (my two personal favorites...) force a sync after modifying a wallet file.

I'd start with this:

Open pywallet.py in a text editor that can deal with Unix-style lines endings (I'm a fan of Notepad++ if you're on Windows) and search for that error message. Shortly before it, you'll see this:


Replace the "r = True" with "raise", being careful to keep the same level of indentation, and then re-run the --dumpwallet command. This should hopefully result in a more useful error message.

This answer is sort of cheating, but any deterministic wallet (Armory, Electrum, MultiBit HD) should qualify (even if it's not because they do so explicitly), assuming you do a reboot or a sync after initial wallet creation.

Not that it really matters, but that malware wasn't claiming to specifically be a MultiBit executable, it is claiming to be a multi-bitcoin wallet, whatever the heck that is...

Hi, all.

Every so often, there's a new "which wallet is best" thread that appears. The correct answer is almost always "it depends"... there are a lot of options out there, and the best wallet for one person may not be the best for someone else.

It can be particularly confusing for beginners. With this is mind, I've compiled a very simple table which I've put up online here:


There's not much to it so far... just 5 wallets listed, and a handful of columns that I thought would be most important for beginners. Note that I'm intentionally leaving out more complicated features (m of n, cold storage, etc.) because this is just geared towards beginners for now.

I'm very much open to input. If anyone has additional experience with different wallets, or just thinks I'm flat-out wrong with something that's already on that page, please speak up. You can do the whole GitHub fork / pull request thing if you like, but it seems easier to just respond in this thread or open an issue on GH.

I'm hoping that in the end, this will be a good starting point for answering the "which wallet is best for me" question for beginners.

The second half of that post talked about how to be safer when it comes to downloading suspicious executables... in other words, software that might actually be a trojan.

As others have said, it sounds like you're off to a great start!


Which version of Windows? Do you mean using EFS (where you right click, go to Properties, Advanced, and then check off Encrypt), or BitLocker?


There's nothing wrong with MultiBit's encryption, as long as you realize that running brute-force guessers against MultBit wallets is quite a bit faster than against many other wallet types. Brute-forcers can guess around 500,000 to 1,000,000 passwords per second (compared to say 50 per second with Bitcoin Core for example) on a CPU, and possibly faster with a GPU or ASIC. As long as you have a nice long passphrase, you have nothing to worry about from brute-forcing, just be aware that in order to be secure it does have to be longer than you'd need with other wallet types.

Regarding privacy: MultiBit doesn't really encourage the use of multiple addresses, and this leads to some loss of privacy. I think this is fine if it doesn't matter to you (it doesn't matter much to me), as long as you're aware of it.

Regarding backups: Every time you add a new receiving address in MultiBit, your wallet file changes and it must be re-synced with your backups. If you don't often add new receiving addresses, this shouldn't be much of a problem.

Regarding malware: All the encryption and backups in the world won't do you any good if you have malware running on your PC. Along with running some anti-malware software, keeping your PC up-to-date, and so on, I posted some more Bitcoin-specific advice regarding how to avoid trojans over in the bottom half of this post. Most of it's basic common sense sort of stuff which you already seem to have a lot of though... 

Maybe this is already obvious, but there's no reason to avoid using a potentially compromised entropy source assuming that you're also using a source that is likely to be good, is there?

In other words, why not use a shuffled deck + CryptGenRandom() (even though it's closed source) + RDSEED/RDRAND (even though it can't be inspected) + whatever else you can come up with? Even if one or more of those methods is insecure, the result is secure as long as at least one of those methods produced enough real entropy, correct?

You're right, the unencrypted seed is all hex, I completely missed that. That reduces each check from three AES block decryptions down to just one, and as you noticed makes an extract script possible which only extracts half the seed, still leaving 64 bits of unknown entropy once/if the password is found. I'll definitely be incorporating these improvements and an extract script for Electrum, thanks for discovering this!

TL;DR: Please try running Memtest86+, this worked for me!

About two or three weeks ago, I was having the worst problems getting past the Sync step. I spent probably about a week or two re-downloading the Bitcoin blockchain (more than once), rebuilding the Armory DB (several times), and rescanning, and it would always fail during the scanning phase with that same "Cannot get tx copy, because don't have full StoredTx!" error often at different points (at different %'s completed).

I became convinced there must be a bug somewhere in Armory. On one occasion in the debug log, it mentioned an additional error message "Invalid txIndex at height # index #". This gave me a place to start looking in the LevelDB database to see if there actually was a corruption. After quite a bit of digging, I did indeed find the issue: in the DB, each transaction in a block is given an ID starting at 0 (that's not the blockchain TxID). There was a transaction in the block whose sequential ID number was greater than the total number of transactions in that block (which is recorded separately in the DB). But how did this happen??

Looking at the transactions that should have been in this block, there was also one missing, so it looked like the corrupted transaction matched up with the missing transaction except for it's sequential ID. Looking closer, the ID was almost correct: it had just a single-bit error in its high nibble, flipping a 0 to a 1 and making it too large.

Well that's strange... maybe my hard drive was failing? Usually HD failures doen't cause single-bit errors, but rather entirely unreadable sectors or relatively large corruptions though.... Maybe a failing RAM stick?

Well, very long story short, I did indeed have some bad RAM which Memtest86+ found pretty quickly. After replacement, I had no trouble rebuilding and rescanning.

A big thanks to Armory for helping to find this bad RAM! If it weren't for all of the double and triple checking in the Armory code, this could have gone undetected for months, and who knows what I could have lost!! Thanks!!!

Thanks for the compliment, flattery will get you everywhere

Getting what btcrecover needs from the pywallet dump is pretty easy.... if you actually manage to find the password, we can worry about the rest later.

Save only the "mkey" section from the pywallet dump to a new file, e.g. it should contain only something like this:


The Python script below produces output in the same format as extract-bitcoincore-mkey.py, but it uses the file above instead of a wallet.dat file. Give it the filename from above as the first argument, and it will print out some base64-encoded stuff that btcrecover can use:


Then you can feed that into btcrecover like this:


If the dictionary file is particularly long, it might be worth trying to get the somewhat experimental GPU support working-- it can improve speed w/Bitcoin Core wallets from somewhere in the 50s to somewhere in the 1000s (tries per second), but it can take some effort to get working well.

Good luck!

Yeah, btcrecover has a lot of scaffolding to actually generate the passwords to test... still that's faster than I expected.
 

That could be true (I doubt PyCrypto uses AES-NI). Although the oclHashcat guys have done some impressive things, including password generation and AES decryption all on a GPU, which is far more than I've managed (I only do SHA's for Bitcoin Core in GPU, everything else is in CPU).

Yup, that's exactly what I'm doing in btcrecover here. I'm only managing around 10^5 tries/s per CPU core (it's written in Python but uses libraries for SHA and AES written in C) but I'd guess it could be improved if written entirely in C, or even better in OpenCL....

It turns out that you can play similar tricks with many wallet encryption schemes (but not with Armory as far as I could find - Armory really got wallet encryption right).