Bitcoin Forum

1. Create a deterministic wallet.
2. Choose a unique username, or email address ... or whatever unique identifier you want.
3. Get an initial small amount of BTC into it (e.g. buy them)
4. Use some of this BTC to write an encrypted version of the wallet into the blockchain (using a messaging service (https://en.bitcoin.it/wiki/Block_chain_message_service)).
5. Delete unencrypted wallet.

From this moment onward, all you need to access your wallet is an internet connection, the bitcoin client, and your username + password.


Was this idea discussed? It would be sweet to have this wrapped in a standard bitcoin client ... no more need to back anything up.

Or you could just use your password as seed for creating private/public keys and wouldn't have to store anything.

What advantage does this have over a normal deterministic wallet?

1.  Create a deterministic wallet using a memorized seed.
2.  There is no step 2.

Either way you have to memorize (or otherwise securely store) a cryptographically-strong seed/encryption key, and either way you get the same benefits.

I don't understand. If it's deterministic you don't need to store anything. Remember the seed => restore wallet. Or are you thinking of some other usage scenario?

This is terribly insecure. You think you're good at remembering a strong password— but you're not.  No one should be creating passphrase based wallets, they should use a small amount (just 128 bits is enough just a dozen or so random english words) of stored pure entropy as well.   ... but storing that in the blockchain would defeat the purpose.

Actually, I use different 16 chars passwords for everything. I keep them stored in an encrypted KeePass database, which is protected with a 49-chars passphrase which is a sentence I chose at random from a book I don't own and I never read (no, I'm not joking, I opened a book in a library and read a sentence). But I'm offtopic.

On-topic, I use Electrum, which uses a 32 chars seed for the deterministic wallet. The seed can be reconstructed with a 12 words mnemonic. I can't remember the seed, but I do remember the mnemonic, so I would say that there's no need to store the wallet in the blockchain, I don't see how it adds security.

Unless, of course, OP was thinking of something else.

I think the OP should clarify the suggestion.

This isn't a very good technique.  If you're highly paranoid, there are lots of scanned books in the world, and well-funded attackers have large libraries.  If you're not paranoid, it's just an awkwardly long passphrase.


This works very well assuming good random selection and that you preserve entropy when you reduce it to 32 characters.

Still waiting on OP.  :)

I'll take my chances with my passphrase against the scanned books of the world :) Anyway, if someone has enough motivation and access to get my encrypted passwords database I can assume he has the means to make me say the passphrase (see here: https://www.xkcd.com/538/ ).

Thus you fall in the "not paranoid" case.  :)

Hmm, I was't thinking of deterministic generation from a seed passphrase.
The way I thought of deterministic generation is that it eliminates the need to re-backup your wallet all the time (but you still need to back it up once), but didn't picture a procedure where you just memorize a single phrase and reconstruct your wallet from that. Nice to know it works like that.

Any plans of deterministic wallets making it into the standard client?

It's good that the book has little relation to you (unlike a pattern derived from my favorite Greenlandic poems), but that the characters are words in a presumably meaningful grammatically correct sentence reduces your entropy significantly.


Each of 'take' (60), 'this' (21), 'as' (17), 'a' (6) are among the sixty most common words in the English language. Their entropy is about as good as a single character. The others might be among the most common thousand words. I would assume this passphrase is much worse than the 16 character passwords they protect. You might need to add another sentence from another book (in another language). But if it's easy to remember and you don't mind typing 49+49 characters, I should think that's reasonably secure.

Sixteen printable ASCII characters has about the same entropy as eight unrelated obscure (among the 5000 most frequent) English words.

Indeed. That provides adequate security (FWIW, I encouraged this approach over an earlier version which just used a user provided pass-phrase, and it was actually what I was thinking of when I used the number 12 for the number of words).

"fancy" attempt, e.g. the phrase from a book you don't own may be less secure than you expect.  E.g. assuming 80k words in a book, 80k books in a library, testing every 16 word sequence from every book in a library would only take about two hours at 1 million attempts per second! (assuming you had the digital data already).

I calculated the entropy of my passphrase when I chose it, and it was good enough. It was less originally (but still over 5000 years to crack), anyway I altered the phrase a little (played with caps, special chars, and so on). I am pretty confident that my super-secret password is safe :)

This seems close to what I used (I can't find the original calculator): http://blog.shay.co/password-entropy/

That blog post incorrectly assumes the same value space (even distribution though 27 possible characters) rather than considering the words themselves as part of a its own space.

carrot ways base split

f#Mo1e)*TjC8

These two passphrases have the same entropy if we make the gross assumption that each word is randomly or equally distributed through a 373300 word vocabulary, a vocabulary much greater than a typical native speaker, including alternate grammatical forms.

However, these four words are among the 5000 most frequently used words in English (way:84, base:939, split:2933, carrot:4650) making it weaker than seven random characters, such as:

f#Mo1e)

Of course, if you have added unpredictable misspellings, random punctuation, removed the most common words, added some cyrillic, then sure, you've probably got an excellent passphrase.

TL;DR: the blogger erroneously assumes that these have equivalent entropy:

So netrin:

I asked before and I'll ask again, I'm genuinely curious:

Are there password-cracking algorithms that attempt passwords from lowest-entropy-to-highest-entropy?

Is it even theoretically possible to sort passwords by "entropy" ?  (seems like a hard thing to easily measure; password "a.b..c...d....e.....f" has low entropy, but would any password-cracking algorithm try it before 6 random characters?)

Yes, all serious brute force algorithms do this.  Implementations vary, but your example will come relatively early in most sequences.  The high repetition count and sorted characters will put it far ahead of shorter high entropy passwords.  The increasing number of dots will probably be missed.

edit: It probably won't be found before 6 random characters, but it would easily be found before 9 random characters.

So what messages would be worth storing in the blockchain?

Yes, but there is no one useful definition of entropy— you don't know the prior.  

E.g.  http://openwall.info/wiki/john/markov (http://openwall.info/wiki/john/markov)  assumes one kind of prior (that your password is the realization of a markov random walk with some measured transition probabilities— something that was shown to be a pretty good model of real passwords in the literature). You can even use it to sort pre-existing wordlists.

There is of course the zero information prior— e.g. the uniform one, where you'd conclude that "password" and "jxiesotm" are equally good passwords. But it's not very useful.


Perhaps your alterations are sufficient, I can't say— but you're making a fundamental error here by assuming an entropy measurement tool can tell you anything useful.  All tools can really do reliably is give you upper bounds on the entropy (e.g. saying that 'password' and "jxiesotm" each could have as much as 49.3 bits of entropy (assuming a 72ch charset)).

You can try to guess a tighter bound than that, but you'll be wildly off depending on if you got the model right.

If choosing 16 word phrases verbatim from books were something people did often enough for an attacker to adopt that prior than your password would only have (assuming my really armwavy numbers of 80k books of 80k words) about 32.5 bits of entropy in that model.  You can insist that some tool says that 16 words magically gives you 500 bits of entropy, but it simply isn't so if you picked those words out of a book. Even without ever having the actual book I can make much stronger predictions just by knowing that the words are comprehensible english.

[9, 9, 9, 9]  < do these numbers have very low entropy?  You can't say from just looking at them. What matters is how they were generated.   How about [140, 166, 77, 233, 193, 177, 35, 167]? (It seems like it has high entropy but it's just a DES encryption of zeros with a key of zeros).


Ideally, what you want to do is to make the zero information prior the correct prior by choosing uniformly. This is removes the risk of the attacker beating the odds with better predictions of password choices because there is no way to beat the uniform prior if you're actually using the uniform prior and it's not easy for you to confuse yourself about how much entropy you actually have.