You're right, Bitcoin keys cannot be feasibly brute-forced.

But this thread is talking about brute-forcing the password on wallets. If the password is weak enough, or if you know enough about the password, it's certainly feasible (and a GPU can help, depending on the wallet).

As far as using a scripting language goes: yes they are slower, but many scripting languages implement the time-consuming portions (e.g. SHA) in native code, so using a scripting language isn't as big of a performance hit as you may think (btcrecover is written in Python, for example, but most of the crypto uses native code libraries (not written by me) or OpenCL for GPU acceleration).

Moral of the story is: use strong passwords.

It should look something like this:


In this example, it's been running for 6 minutes so far, and it has 29 minutes before it's tried every combination.

If it finds the password, it will look like this:


Or if it tries every combination and the password is something else (e.g. maybe it's longer, or has numbers), it will look like this:


Does that answer your question?

I hope so too. If not, but you remember something new about your password, we can always try again.

I'm not understanding you... can you describe in more detail? A bunch of examples would help.

It also depends on which wallet you're using.

Services like BitUndo can attempt to reverse a tx before the next confirmed block, but they remain very unlikely to succeed (even as per their own FAQ). BitUndo depends on miners running a customized version of bitcoind, and thus far the interest in doing so has been pretty low.

I should have caught this sooner, but now I see the problem.

You have Python 3 installed. btcrecover only works with Python 2. (They are similar, but different programming languages.)

You can have them both installed at the same time, but it's probably safest to:

  1. Uninstall PyCrypto
  2. Uninstall Python 3
  3. Install Python 2.7.8 Windows X86-64 Installer from here.
  4. (optional) Install PyCrypto 2.6 for Python 2.7 64bit from here.

Thank you for the picture, it is very helpful.

I understand what the problem is, but I can't fix it tonight, sorry about that.

I'll post an update tomorrow sometime...

The different languages thing is hurting us... but I'll try.

From the Quick Start, follow Step 1 to install everything.

Next, open Notepad, and then copy and paste this into Notepad:


Next, save the Notepad file into the btcrecover-master folder you unzipped from Step 1. The file name must be btcrecover-tokens-auto.txt

Next, follow Step 5 from the Tutorial Quick Start. After you find your Multibit .key file, copy it into the same btcrecover-master folder, and then rename the .key file to multibit.key

Finally, double-click btcrecover.py, and it should start.

If you installed PyCrypto in Step 1 (optional), it will take an hour or two to finish. If you didn't install PyCrypto, it will take around 6 - 24 hours to finish.

This will test every password from 1 to 6 letters long. The first letter is upper or lower case, the rest are all lower case. No numbers or symbols.

Good luck!

Bitcoin wallets all (that I know of) use strong encryption. The point is to protect you from hackers. This also means that if you lose your password, you could be in trouble.

If you describe everything you remember about your password, I can try to help. You don't have to use specifics -- for example you could say "I know my password contained 3 - 5 of these words below, and then a 1 - 2 digit number" and give example words, but not the actual ones you had in mind.

If you want to use Bitcoin in the future, look into a "deterministic" wallet, such as Electrum or Armory. They have easy backup-to-paper and recovery mechanisms that can help.

btcrecover might help, but only if you remember a decent amount of your password. It does support Multibit, although it doesn't support non-ASCII letters, so if your password had any umlauts it won't help. There's a tutorial with a quick start here (in English, sorry).

This thread has a lot of good information related to password recovery, but some of it is specific to Bitcoin Core (Bitcoin-Qt) wallets.

If you have any specific questions about btcrecover, let me know and I'll try to help (I'm the dev).

I'm going to generalize here, but it's not that far from reality.

Let's divide all Bitcoin users into two categories:

Computer knowledgeable: individuals who are either computer enthusiasts, professionals, or who are neither but have made a real effort to educate themselves on basic computer security.
Not computer knowledgeable: not trying to be condescending, but everyone else...

Likewise, let's divide malware into two categories.

Simple Trojans: written by beginner programmers typically in a scripting or bytecode-compiled language, such as AutoIt, Java, .Net, etc., and does simple things such as scan for wallet.dat files in well-known locations and uploads them to FTP servers; is thwarted by wallet encryption with anything but simple passwords.
Advanced malware: written by professional black-hats and sold on the black market to individual who customize and deploy the malware; is capable of exploiting one or more OS or application vulnerabilities, attempts to hide from anti-malware products and security sandboxes, and will patiently search for a variety of information to steal (or encrypt for later extortion) from a variety of locations (including typed passwords, screenshots of on-screen keyboards, and who knows what else).

User Type	Likely to be infected by advanced malware?	Likely to encrypt their wallets?	Likely to follow your advice?	Likely to be infected by simple malware?
Computer knowledgeable	Yes	Yes	Maybe, but they know it wouldn't do them much good.	No
Not computer knowledgeable	Yes	Maybe	No, even though it would help them.	Yes

In other words, I would argue that the type of user that this sort of security-through-obscurity would help (those who get infected by simple Trojans) is the same type who wouldn't know enough to implement this advice (or for that matter, to even encrypt their wallets in some cases which would help against simple Trojans).

Glad to hear it, this was the only major concern I had. 


I really should have made it clear what I was looking for, instead of suggesting some sort of solution first. I was mostly talking about a simple recovery mechanism for a lost 2fa that didn't involve email or one's phone. You're already considering a paper-based 2fa, which sounds like an even better way to address this, so that's great!


I'm not sure what an "open" API is (please excuse my ignorance), but they do publish their API online. One method they support is OATH-HOTP based (very similar to Google Authenticator, except instead of the time they use a counter which is incremented after each new code). The only reason I thought of them is because I use them with LastPass (on my desktop). I was thinking they could be both a desktop and a mobile solution, but I don't really know anything about their mobile integration (it's NFC based).


I should have realized that, thanks for correcting me. Adding such an option would only lead to a false sense of security, please pretend I had never mentioned it in the first place. 

For what it's worth, I've been really impressed with your overall approach. I really hope GreenAddress gets the attention it deserves!

OK, I'll buy that. So there's a non-zero chance that the scammer will get away with it scot-free (get their btc back), but in every scamming attempt, the scam attempt will result in a 587/600 chance that the receiver doesn't receive any btc (unless they want to try a cat-and-mouse game of some sort with the scammer up until the next block is found).

A rational scammer will only try this scam if their expectancy is > 1, in other words if the refundable fee is < than some smallish %. But a scammer who places value on the thought that the receiver will not get paid can execute the attack at will (albeit in return for the surcharge), with the added bonus that they also might get their btc back.

This means that the vendor needs a higher refundable fee to discourage such practice, and they also need to add a non-refundable surcharge to cover their losses. As long as this surcharge is less than 3-ish percent, it will be comparable to credit cards (which removes an advantage of Bitcoin from a vendor's point of view).

Now that Bitcoin is gaining some public traction, explaining all this from a PR point of view would be just about disastrous, if you ask me. To consumers: you have to pay an extra 10%, but it's refundable. To vendors: any consumer who wants to can rip you off, even though they aren't likely to benefit financially, so it probably won't happen much.

But more importantly, what is it that we'd be left with? A more complicated system (both technically and PR-wise) that that accomplishes the same thing as what we had before: instant payments still aren't guaranteed, and so they cost the receiver. So where's the advantage?

If anything, I'd prefer a Pay by Fee that didn't include scorched earth. At least there I see some small advantage: nobody should trust zero-conf transactions (although I still don't like it).

Hi tryexcept, I have a couple of suggestions re 2fa I'm hoping you can consider.

The one thing that's keeping Google Authenticator a bit unsafe is that the same code can be reused (if it's within the same 30s window). This is something that could be abused by malware, and one of per-tx-2fa's biggest draws for me is safety from malware. I'm wondering if an option could be added to prevent the reuse of GA codes? I understand that some users would prefer not to have a once-per-30s rate limit, hence making it optional might be better than forcing it on everyone (although for myself the rate limit wouldn't bother me).

Second, how about an OTP option for 2fa? For example, I enable OTP as a 2fa method, and then ask GreenAddress to generate two or three OTPs which I store on Post-Its. I enable Google Authenticator, but I don't enable any of the other 2fa options because I consider them less secure. Now I've got a few OTPs that I can use to disable 2fa (or for any other 2fa-required action) if at some point in the future I lose my Google Authenticator, and at the same time I don't have to enable any other 2fa method.

Next, have there been any thoughts on 2fa hardware tokens, e.g. YubiKey NEO (which would work nicely with the mobile app w/o the silliness of having the second factor be on the same phone as the app)?

Lastly, how about an option to require 2fa during the initial login? The intent would be to prevent a loss of privacy in the event the mnemonic were compromised (e.g. via malware).

I look forward to your thoughts, thanks!

The best place to start looking is the official choose-your-wallet page here: https://bitcoin.org/en/choose-your-wallet

There's also a beginner-friendly chart that I've put up here which might be helpful: http://gurnec.github.io/btc-wallet-comparison. If you have any questions on why I rated something the way I did on that chart, just ask.


Yes. Before starting Bitcoin Core for the first time, create a new folder on an alternate drive, and then modify the shortcut in the start menu (right-click, properties) so that the Target includes the newly created folder, like this:

Also, by placing a "bootstrap" file into this folder before staring Bitcoin for the first time, you can significantly speed up the initial download process (from days to hours). This bootstrap file can be downloaded via BitTorrent with this torrent: https://s3.amazonaws.com/bitcoinarmory-media/bootstrap.dat.torrent.

(I can't believe I'm letting myself get dragged into this, I should know better...  )


Let's see, how about:

• this server we're all posting to
• Google
• the phone in my pocket (IDC says Android has a 78% market share as of 4Q13)
• the TomTom in my car
• the wireless router under my desk (and possibly your wireless router too)
• 485 out of the top 500 supercomputers (as of June 2014)
• the International Space Station (where it replaced Windows in 2013)

It really is all over the place these days, despite it's low desktop OS adoption rate.


Or maybe Safari, the browser built on top of the open-source (though Apple-backed) WebKit project?

TL;DR: the main point is that Pay by Fee isn't a simple issue, and it’s as much a technical issue as it is one of human nature.


To be fair, I think (but am not sure) it was luke-jr who initially decribed this, and jdillon who expanded on it.

Also, I don't think you have the description quite right.


I think you mean, "If a scammer tries to double-spend their own Bitcoin by sending out two transactions, one legit and one back to themselves, there is some chance they will succeed and the receiver/vendor will be none-the-wiser until it's too late."

I don't understand where the percentages you go on to quote come from, though. There is some chance that the receiver/vendor will see the legit transaction in their memory pool, and some chance they will see the scamming transaction (and react accordingly), but it's not 50/50. Likewise with the chances that one transaction will end up succeeding over the other.


I think you mean, "If a scammer sends out two transactions, one legit and one back to themselves, the receiver/vendor will eventually (assuming a significant majority of the network/miners is using Replace by Fee) see the scam transaction, which is good for the receiver/vendor, so the receiver/vendor can send another transaction paying 100% of the output of the transaction to a transaction fee (to a miner). Scammer receives nothing, but neither does the vendor.

No arguments from me here.


You're assuming that all receivers/vendors will be smart enough to check for this situation and react to it quickly (which might be the case one day, but the reality is that there will be a transition period while this is not the case). You're also assuming that the scammer is choosing to act rationally.

Even if the scammer only has a low likelihood of success, I don't see why a scammer wouldn't try anyways. Some percentage of the time the scammer would fail and would end up paying for their merchandise (although they'd be paying a miner instead of the vendor). Some other percentage of the time, the scammer would succeed and get their btc back. It seems to me that the scammer, at least during the transition period, has nothing to lose by trying, and is guaranteed to at least deprive the receiver/vendor of their payment.

To be fair, jdillon also had a clever solution to this problem (linked above), but it involves requiring all senders/consumers to overpay for their merchandise/service, and then trust the receiver/vendor to refund them the difference after the tx has been confirmed, which seems unfriendly at best.

The bottom line is that Pay by Fee seems likely to completely eliminate zero-conf transactions, or at least during the transition period. Some would argue that this would be a good thing, but I'd rather let receivers/vendors have the choice to make their own risk/benefit analysis.

The admin over at cryptocointalk has responded here: https://cryptocointalk.com/topic/13908-zipcoin-zipc-information/?p=116770.

Given the choice between believing an admin over at cryptocointalk versus a newbie here... well, I'll let everyone come to their own conclusions...

The only thing I can imagine is that OP posted the legit link, waited for bitointa.lk to cache it, swapped it for the malware link for a period of time, and then swapped in the legit link again (or there's some sort of conspiracy against OP). Without a mod to check all this, we'll never know for certain how it happened, but in the mean time, I'd avoid this coin like the plague.

I doubt that 


Thanks for clarifying.

That's not the file in question. As far as I can tell, that file seems clean (but again, unless it's compiled via Gitian, it's very hard to tell).

The file in question was allegedly originally available here, but as I said has since been remove: https://mega.co.nz/#!JAoyiajC!0ND16g-6qVDRGVuxnNBZmd-NInXzpbdaW9Pe9dDlDUo

The suspicious file, which as far as I can tell was first referenced by user oreoeater in this post: https://bitcointalk.org/index.php?topic=721306.msg8198136#msg8198136  is still available here: https://mega.co.nz/#!L1IBwTzB!sHUsuf3fLQ-PJrtScL7IZaT99DPNesSSrUfJ_ehFjkg. It's definitely malware, see here: https://bitcointalk.org/index.php?topic=721306.msg8201918#msg8201918. I think oreoeater may have uploaded at the request of others looking to investigate it, but I haven't read the whole thread so I'm not sure.


Or did the admin simply copy and paste the link from somewhere else? Those are the questions, and I hope the admin will respond (over here).