If the passphrase has structure to it, than a sophisticated attacker can take advantage of that structure to reduce the search space. Just to be clear though... I'm not a sophisticated attacker, so please don't ask me how such an attack might actually work, or how successful a sophisticated attacker would be in attacking this particular style of password... I just don't know.

My "not knowing" is the point, though. Given these two options, which is better?

• A private key generated from a good random source, which has a known amount of entropy and a known likelihood of compromise via private key brute-forcing (practically none).
• A private key generated from someone's brain, with an unknown amount of entropy and an unknown likelihood of compromise via private key brute-forcing.

The former is always safer exactly because the latter is an unknown quantity. Unless there's some real benefit for using brain wallets, the fact that they might be insecure (definitely so in many cases) is enough reason to avoid them entirely. After all, why make life easier for an attacker, even if it turns out to only be a little bit easier?

(If there were some other security advantage to brain wallets, this might be a different story, but there aren't any...)

Your passphrase probably isn't more secure than Electrum.

A nice thing about an Electrum seed (or a BIP39 mnemonic) is that we know exactly how it's created, and therefore we know that it contains very close^* to 128 bits of entropy. That means that brute-forcing it would take, on average, about 170 billion billion billion billion operations.


It's not as much entropy as some wallets, but it's still a whole lot.

The problem with your scheme (nearly all schemes for that matter) is that we don't know how much entropy it actually contains. Unless you describe exactly how you created your conlang, and then describe exactly how you construct your passphrase, there's no way to know (and even then it could be difficult to figure out).

This is at the heart of why brainwallets are bad. Humans are bad at creating entropy using just our brains, and we're really bad at estimating how much entropy something has, and in the end it's the amount of entropy in a key that makes it difficult (or not) to brute-force.

So is it possible that your scheme is safe? Maybe, but it's unlikely (given the last sentence above) and impossible to say for certain (given that you didn't describe your exact scheme). It's always safer to go with a solution whose strength we know -- there's no real reason to invent your probably-unsafe own.


* Electrum is only as secure as its underlying source of entropy, which is /dev/urandom on Linux/BSD/Mac OS and CryptGenRandom() on Windows. Although there are no known weaknesses in current versions of either, both have had problems in the past, so it remains possible that the actual amount of entropy could be less.

I've no idea... none has admitted doing so. At least one of the recovery services predates the initial release of btcrecover, but that doesn't mean that a recovery service couldn't be using btcrecover today, if they felt it was better than whatever the used to be using.

(Not that there's anything wrong with a commercial service using btcrecover -- it's released under GPLv2 which means that anyone is welcome to use it, even for commercial purposes, as long as it's not redistributed in closed-source form. Of course, a mention is always nice )

Hopefully not lost....

Try running bitcoin-qt with the -rescan option. E.g. if you're on windows, close the app, and then go to Start -> Run, and type:

It sure makes you wonder....

http://usatoday30.usatoday.com/tech/science/discoveries/2007-02-07-neolithic-love_x.htm

I don't know the full answer, but I can give you a handful of pointers.

• The mailing list is a good place to discuss Bitcoin Core implementation specifics, especially non-trivial changes. (It's not a good place for arbitrary questions / thoughts about Bitcoin Core....)
• The coding guide is an essential read.
• There's also a lot of discussion that goes on in the GitHub repo, especially in pull requests -- if you're thinking of implementing something, I'd check here to see if someone might already be working on it, or if the idea has already been tried but had some issues.

This is not a link to JackJack's new pywallet. This is an attempt to distribute malware.

Do not use the fake pywallet software in this link, it is malware. It will steal your wallet file and upload it to the attacker.

Ignore any pywallet download links which are not posted by JackJack himself.

edited: the scam post has been deleted; removed yelling.

I thought we were having a discussion about comparing the pros (just one: 100k less disk space) and cons (significantly worse security) of a brain wallet compared to a traditional wallet. What you're saying is that it's more about the coolness factor.

I agree, it seems pretty cool to be able to store a bitcoin wallet entirely in wetware. However I stopped using "coolness" and started using logic to help me make decisions somewhere around the age of 15.

If we can't agree on an underlying method of reasoning to use for the decision making process, then I don't think there's anything left to discuss. It'd be like trying to prove evolution to a creationist.

For individuals who do believe in deductive reasoning, traditional wallets are always superior to brain wallets, and therefore brain wallets should never be used. Others are welcome to use whatever method of reasoning and whatever wallet they like.

vanobe,

I (for one) appreciate your interest in this, and I agree it could theoretically lead to a wallet theft, but it would do wonders for your reputation if you didn't reference articles that are

• full of alarmist FUD,
• technically inaccurate in some aspects (e.g. the claim that PHP is completely invulnerable),
• not a respected source of security information,
• full of advertisements.

For example, the Red Hat security blog would have been a much better choice. (edited to add: oops, which I see you did include, silly me)

Yes, and in some distros bash is the default /bin/sh shell (but not all, e.g. recent Debians / Ubuntus uses dash).

In order to be vulnerable, an attacker must:

(a) convince a process to set an environment variable to a value of the attacker's choosing, and then
(b) convince either that same process to spawn a copy of bash, or convince a child process to do so.

I don't think there's any way to convince Bitcoin Core to do (a), so it seems unlikely that Bitcoin Core could be an attack vector for this (but I'm not positive).

If that's the only advantage, it's a pretty small one compared to the inherent decrease in security.

Can you really not afford the storage space of a 100 kilobyte wallet file?

That's not a stupid question at all...

See this thread for a discussion on methods to transfer your private keys from a blockchain.info wallet into other wallets: https://bitcointalk.org/index.php?topic=594570.0

That depends on what "did a MtGox" means, since we still don't know exactly what happened there...

I thought I answered all of these in my first post here, but maybe I was unclear.

If blockchain.info is hacked or if they have a crooked employee, there's some chance they will be able to steal your bitcoin (see my first post...)

If blockchain.info disappears, than as long as you have a recent* backup, (via one of the backup mechanisms on their web page), than you will be able to recover your bitcoin.

*by recent, I mean you haven't created any new receiving addresses since your last backup.

(ignore the generalization from Velkro which doesn't apply to blockchain.info...)

As long as your password is strong enough, I wouldn't have an objection to either (or even better, both).

By default, blockchain.info wallet passwords use poor key stretching. Before backing up your wallet online, I'd go into Account Settings -> Debugging, and change the PBKDF2 Iterations setting from its default of 10 to the max available of 20000. (For comparison, Bitcoin Core typically uses an iteration count that's about 10x higher than this).

I agree with most of this, but I have to disagree with "it can actually keep your coins safer than a desktop wallet."

One disadvantage of desktop wallets (as I'm sure you know) is that they are vulnerable to malware. Some types of online wallets (and mobile wallets in some cases, too) offer very good resistance against locally installed malware, but only if the online wallet implements per-transaction two-factor authentication. Blockchain.info only offers login two-factor authentication, which can protect against online (but not offline) brute-force attacks, but it doesn't prevent locally installed malware from stealing bitcoin after a user has logged in.

More technically speaking, malware can wait for you to log in, and then capture your password (it doesn't need to capture your 2FA code). Once you've logged in, your PC downloads the encrypted blockchain.info wallet. At this point, the malware has access to both your just-downloaded wallet and the decryption key (your just-captured password), and that's all it needs to steal bitcoin. In this manner, blockchain.info is essentially the same as a desktop wallet, except that the software and the encrypted wallet file are loaded from a remote server during each use.

There are several different ways you could lose bitcoin stored at blockchain.info.

• 1- Hackers break into blockchain.info's servers, steal your encrypted wallet, and then brute-force the password (if the password isn't strong enough).
• 2- Hackers break into blockchain.info's servers, steal your encrypted wallet, and replace the website with a look-alike which then steals your password. This type of password-stealing attack would eventually be detected, but it's impossible to guess how long it would go undetected. You would be vulnerable if you log into your wallet while the attack was still undetected.
• 3- An insider at blockchain.info executes the attack described above. Also as above, the attack would eventually be detected.
• 4- A piece of malware finds it's way onto your PC which targets blockchain.info. The next time you log into blockchain.info (even if you've enabled 2FA), the malware can steal your bitcoin.
• 5- You do not maintain backups of your blockchain.info wallets, and blockchain.info loses your wallet or closes up shop. By maintain, I mean that you need to back up your wallet after each new receiving address is created.

It's impossible to estimate the likelihood of any of the above happening... are there one or more of the above that particularly concern you?


Can you be more specific? Is it that Bitcoin Core is too resource-heavy? Are you talking about malware? Something else?


The only wallets which approach 100% trustworthiness are cold storage wallets and hardware wallets. If you're (like me) unwilling to deal with the inconvenience or cost of these solutions, you'll need to make some compromises...

Regarding "a virus embedded in various wallets": In order to send a transaction from any wallet (brain or traditional), you need to run software. It's then just a question of where you get the software, and do you trust the software's authors. Because traditional wallets are more popular, they have many more eyes on them, and there is much more peer review. Due to this, I'd argue that popular traditional wallets are safer and less likely to have embedded viruses than less popular software.

Regarding stolen wallet.dat files, and malware in general: Brain wallets offer no additional protection over traditional encrypted wallets.

• If your brain wallet password is weak, your brain wallet is vulnerable to anybody (which I'm sure you already know). If your traditional wallet password is weak, your traditional wallet is vulnerable only to locally installed malware. In other words, having a wallet.dat file on a hard drive is not less secure than using a brain wallet, as long as the password is strong, and given a weak password, a brain wallet is far more vulnerable.
• Both wallet types are equally vulnerable to malware the instant you type your password in order to send bitcoin.

Regarding hardware failures: Backing up an HD wallet is no more difficult than backing up a brain wallet. You simply write it down or print it out (once). Such a backup will protect you against any type of hardware or wetware failure.

Regarding ease of use: this is more a personal opinion -- if you think brain wallets are easier to use, that's your prerogative. However you should weigh this ease-of-use against the inherent security risks of using a brain wallet: is it really that much easier to make it worthwhile?

I agree it's likely if you're doing a lot of audio editing that you probably would have noticed a hardware issue, but it's still possible that there's a hardware issue. The only way to be certain is by testing (e.g. an error scan with HD Tune or a "Scan for and attempt recovery of bad sectors" in Windows...)

From my own personal experience: when my DRAM died, the only applications I had trouble with were Armory and Bitcoin Core. Everything else (for example compilers and games, both of which are hardware-intensive) seemed fine. It was only after I ran Memtest86+ that I was convinced it was my hardware's fault, and not Bitcoin Core's.

Another possibility is a DRAM memory problem. Memtest86+ can help to rule this out (or in): http://www.memtest.org/#downiso

Also, just FYI, because Bitcoin Core can be both disk and memory intensive at times, it wouldn't be surprising if it were the only app that was having problems. In other words, there might be a hardware problem even if all of your other apps are running just fine.

No guarantees it's a hardware problem, but it's definitely a good thing to check for.

Well, although I'm kinda happy (sorry) that something weird and mysterious isn't going on, I'm unhappy that this could make things more difficult for you...

On the (small) plus side, you already have JtR compiled, so if you'd like to use it to search for your password, it's a great option.

btcrecover is faster if you have a discrete video card, in terms of guesses per second (and JtR is faster if you don't have one). I also think that btcrecover is the easier option if you already have a good idea of what your password is, but I'm just a teensy bit biased (I'm the author of btcrecover)....

If you do choose to try btcrecover, the tutorial and quick start is here: https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#btcrecover-tutorial

Let me know if you have any questions.