There's a good reason you can't compile it... the source code isn't complete. Even it it were, the source code which is there is clearly just a 99% copy of CGMiner, except for removing any references to the CGMiner name and replacing some of the copyright notices (which itself is a GPL violation...) with bogus names ("Michael Bubble"? really?). In short, the binaries and the source code are not the same.

Just because something claims to be open source, doesn't make it safe.

I guess that depends on your definition of "subtle", but one thing is for certain: there's some new piece of malware posted on the forums every couple of weeks, and it's been getting a bit more clever each time. This is a trend that I'd guess is very likely to continue.

Take this one for example. The website it points to looked surprising professional even though it had some broken links (it's currently down, so you'll just have to take my word for it). It wasn't posted by a newbie which gave it a little credibility (I'm pretty sure the forum account it was posted under was hacked). The malware itself wasn't all that clever given that it tripped a bunch of antivirus (probably some existing RATware if I had to guess), but overall it wasn't immediately obvious.

Here's another one that's a little more clever. Not the nicest looking website, and it is posted by a newbie, but it claims to be open source and even has a link the the supposed source on GitHub. There's also someone who's not a newbie who is somewhat defending it. The malware itself isn't an off-the-shelf package-- it appears to have been custom written and doesn't trip antivirus unlike the first example.

I'd have to guess that these kinds of examples are already fooling at least some people, otherwise why would their respective authors keep bothering (both of those examples were not the first of their kind...)?

RodeoX, baitty, Acidyo, thanks for the kind words.


Yes, it comes from years of trial and error ( mostly the latter...  )

Some of these are repeats... but they deserve being repeated!

• Do encrypt (passphrase protect) your wallet. Don't use a simple passphrase. Don't use a passphrase you use elsewhere. Encryption helps, but understand that it doesn't prevent all types of theft.
• Do backup your wallet. Different wallet software work in different ways: some wallets you only need to backup once, others you need to backup after every new receiving address is created, and others are somewhere in-between. Understand how this works for the wallet software you've chosen, and be vigilant with your backups!
• Don't start off owning more BTC than you can afford to lose/have stolen. If you find yourself getting close to your personal limit, search for "cold storage" and find out how to use it. Don't put this off until it's too late.
• Do choose one of the wallet options from the official choose-your-wallet page here: https://bitcoin.org/en/choose-your-wallet. Not all online wallets are bad, however Do heed the warnings on this page regarding some of the less-safe online wallets. Choosing an online wallet does not exempt you from backing up your wallet.
• Don't download programs from the Internet. This rule is difficult to follow 100%; just be aware that each new program you download and run could be the one that steals your BTC.

Regarding that last rule, here are some guidelines that can help you decide how (un)safe a download is. Note that these are not hard-and-fast rules!

• Do research a program before downloading it. Are there a lot of websites discussing it if you search for it? Does it have a Wikipedia page that wasn't created yesterday? If either answer is No, Do be more suspicious of it.
• Software that is open source, especially if the answers above were No, is generally more trustworthy, but Don't assume that something is safe simply because it's authors claim it's open source!
• Software that is written in a popular scripting language such as Python, Ruby, Perl, JavaScript, etc. is generally more trustworthy, but Don't assume that something is safe simply because it's a script unless you can read and fully understand the entire script! Never download and run something claiming to be a script if it's actually an EXE file.
• Do look at the number of pages in a thread before downloading any software referenced on the first post of the thread. More pages means a smaller chance of the software being malware (but there's always still a chance it could be malware!). Do avoid software with only a few pages worth of posts - let someone else be the guinea pig!
• Do look at the Activity count and the Date Registered of users when trying to decide if they're trustworthy, and be more suspicious of Newbies, but Don't automatically assume that a Hero Member is 100% trustworthy.
• Do err on the side of caution/paranoia. It only takes one piece of malware to steal all of your BTC even if you've encrypted your wallet and even if you're using two-factor authentication.
• If you've decided to risk downloading something, Do take the time to find the single official download link or website.

Sorry if I sound scary... most people around here are the honest type, but there absolutely are scammers around here too. Use common sense, and have fun!

Btcrecover supports Multibit.


Btcrecover (written in Python) doesn't use the Bitcoin RPC API. With Bitcoin Core wallets, on a single core CPU it's around 15% slower. On a machine with more than one CPU core it's faster. There's also experimental GPU support which makes it much faster, if it works at all...

For Armory, it's exactly the same speed (because it uses the Armory library) except that it can use multiple CPU cores which again makes it faster.

For Multibit (classic) and Electrum, it's quite a bit faster than any of the wallet types above because these two wallets unfortunately don't use any key stretching...

The LTC might be a lost cause, assuming you don't remember anything about the password, but why is there a lot of manual work for your BTC? It should just be a single dumpwallet, rename the wallet.dat file, and then a single importwallet, correct?

Firstly, you're hopefully aware if your wallet is unlocked, you can export all the keys at once (unencrypted) with dumpwallet (which can then be imported all at once into a new wallet with importwallet)?

Regarding your password, sorry to be the bearer of bad news, but it is not stored anywhere in memory and cannot be retrieved. When the wallet is unlocked, the password is used to generate a decryption key which is then used to decrypt your Master Key, and then the password is removed from memory (it is securely overwritten). The decrypted Master Key (which is simply 32 random bytes) alone is stored in memory while the wallet is unlocked, and it is used to decrypt individual private keys on demand. When the wallet becomes locked, the decrypted Master Key is securely overwritten.

So to get your LTC back, I imagine your only options would be recovering your password, restoring your LTC wallet from a backup should you have one, or brute-forcing your LTC wallet if the password is short enough and/or you remember some portion of it...

Look here for Windows:

https://bitcointalk.org/index.php?topic=652909.msg7362979#msg7362979

TL;DR: %appdata%\Bitcoin

I certainly understand that point of view, but I thought that it was generally understood that as Bitcoin continues to get more popular, there will be a diminishing percentage of full nodes compared to SPV/lite nodes. Of course it's always good to encourage the use of a full node client, but I see no reason to discourage the use of an SPV/lite client... just my 2c.

I agree with the other posters here that this should work, assuming you back up anything before overwriting it. I'm concerned that in the screenshot you provided, there was a noticeable change in file sizes between the backup files. As long as you get back all of the addresses/keys you need, this seems the easiest & safest option.


The private key backups (at least the ones that MultiBit creates automatically) are encrypted with the same password(s) as the wallet files...

If restoring a wallet file doesn't work, you can try to look for password typos with this: btcrecover (full disclosure: I wrote that...), quick start is here.

Good luck...

Damaging network health...? Can you explain?

The Armory folk maintain a bootstrap.dat torrent you can use. Visit here for the current link to their torrent file: https://s3.amazonaws.com/bitcoinarmory-media/announce.txt. As of today, it's only a couple of months behind.

Once you have the bootstrap.dat file all downloaded, place it in the Bitcoin directory (%appdata%\Bitcoin on windows) before you start it for the first time, and that will speed things up a bit. You can also ask Bitcoin to use more RAM with the -dbcache=# command-line option (I use a value of 2048 (that's in MB) on my 8 GB machine on only the first start, YMMV). If you have an SSD, the initial indexing and the remaining block downloads can be as short as 3 hours. (Once done, the Bitcoin client renames the file to bootstrap.dat.old, and you can delete it.)

The Armory client tries to automate all this, but I've had some issues with it in the past (which were probably my fault...) so I usually do it manually.

Electrum does, though I don't know anything about their (Python) plugin interface.

Armory is adding plugins support, but's only in the initial planning phases now, so it'll probably be a while.

There are some things that sound interesting to me... you get most of the advantages of both running a full node and an SPV or web client (full blockchain validation but lightweight on your client devices).

I'm not sure what you mean with regards to blockchain.info though. Keys are stored encrypted both on their server and in localStorage (but not in RAM). If you enable two factor auth, even the encrypted keys are no longer stored in localStorage by default. Not that it's perfect, in particular their default key stretching is pretty minimal.

Also I wonder how long a $5/mo. DigitalOcean VPS with it's 512M of RAM would take to do the initial blockchain indexing.... you could always beef it up during the initial indexing I suppose.

Justin00 had a good question, but assuming the answer is Yes, I'm thinking it's not worth the effort trying other things if you don't have much in that wallet. It'd be possible to check for single-bit or single-byte errors in the mkey for example, but someone would have to write some custom software to do that which wouldn't be that easy...

Sure sounds mysterious to me...

You mentioned cloning your drive. Did you need to:

  Reinstall the OS?
  Reinstall Bitcoin-Qt?

Do you have an older backup of your wallet file?

Have you made any other recent changes (other than the HD upgrade) to your PC?

Does your passphrase contain any non-ASCII characters (any characters not in this table: http://en.wikipedia.org/wiki/ASCII#ASCII_printable_code_chart)?

If the answer is no to all of those questions, I'd probably try dumping your wallet file with pywallet which might provide some clues.

You can download it from here: https://github.com/jackjack-jj/pywallet/archive/master.zip If you're on Windows, you'll also need Python 2.7 from here: https://www.python.org/download/ (you don't need any other libraries, despite what the README for pywallet says)

Next run it from the command line, something along these lines* (after you unzip the pywallet-master.zip file somewhere):


If any of the private or public keys in your wallet file are corrupted, Bitcoin-Qt will complain about a bad password, but pywallet only checks the first key it finds. In the dump file, check for a message that says "The wallet is encrypted and the passphrase is correct" or "is incorrect". If correct, you probably have a single corrupted key which could be found and removed. If incorrect, then it could be your master key that's corrupted, or the password actually has changed, which might not be repairable....

* If you're paranoid like me, the output file should be something like " > e:\wallet-dumped.txt" where e: is a disposable thumb drive which you can later destroy. One thing about SSDs is that there's usually no good way to securely delete a file from them, and the dump file will contain all your unencrypted keys... if you have a hard disk drive, you could use Microsoft's SDelete (Google for it...).

Would such a plugin directory be located in an only-root-writable location by default, e.g. /usr/lib/armory/plugins or \Program Files (x86)\Armory\plugins? If so, I don't see how it could compromise security unless root was already compromised (in which case all bets are off anyways), correct?

You could still allow a per-user preference to enable/disable individual plugins, but require root/Admin to initially install them.

Every dictionary word? That's not the impression I got from OP's post, s/he said s/he "probably misspelled" their password and that s/he made a "reasonable dictionary" which I took to mean a bunch of likely misspellings.

If he really wanted every dictionary word, that sounds more like a wallet thief than a misspelled password to me (just to be clear, that's not the impression I have).

Regardless, that thread mentioned above has a lot of good info. I'll go ahead and plug my own recovery tool which can help, although I'm clearly biased... a summary is here if you're interested, as is a link to the tutorial: https://github.com/gurnec/btcrecover

No... there are just too many, sorry...

Even if we leave out all non-US-ASCII letters, there are about 95 characters to choose from. That comes out to 6.6 quadrillion password permutations. Let's say you bought 4 of these (assuming it's a real product, I frankly have no idea...) for about $25,000 (USD) total, hired a software engineer to write custom software to use them for password searching instead of mining (maybe another 25-50k ??), paid for electricity and cooling (another 15k or so), then it would probably take less than 6 months to try all of them. Or you could use your home PC with mostly off-the-shelf software and be done in perhaps just 200,000 years, take your pick....  

edited to add: sorry if I came off as snarky... I should have tried actually being helpful instead, like DannyHamilton has graciously done.

Not trying to be mean, but if you're doing this for a commercial service, shouldn't they be helping you out? If you want to try to recover it yourself, which might be hard, this thread might be more useful...