Topic: [Electrum] a brainwallet in twelve words (Read 13318 times)

"How does electrum ensure that each seed is unique and cannot be Brute-forced?"

First Electrum generates 128-bit random number using cryptogen. The seed is then derived from that number.

So yes, Electrun's seed is very safe.

Was there every any more diligence on brainwallet.org? I thought I could download it like bitaddress and make use of it, but it does not seem to run offline?

I did not say it would be bad.

I use 128 bits because 128 bits is secure enough.
Now, if you want to have more entropy, the correct way to do it would be to first pick a random number of n bits, then derive the key from it.
A private key is not completely random, therefore its entropy is less than its length.

Note that even though Bitcoin private keys are 256 bits long, their hash used to create Bitcoin addresses is only 160 bits. So the actual level of security offered by Bitcoin addresses is 160 bits.

Please excuse me while I ask again.
Even if a BTC private key is not a random number, it is unique and is longer (thus more secure). If it can't be guessed, why would it be bad to use as a seed?

The seed is a 128 bits random number, generated by os.urandom()

The seed is represented as a sequence of words in order to facilitate memorization and storage, but it can as well be represented as a hexadecimal string, or as a number.
For some reason, people tend to perceive words as "less random" than numbers. That's an illusion.

The only thing that actually matters is the number of bits of entropy in your seed (128 bits is considered as very safe, and will probably remain safe until real quantum computers are invented), and the quality of your source of randomness (electrum does not use python's random module)



No, that does not make sense. A private key is not a random number.

Quick question:

How does electrum ensure that each seed is unique and cannot be Brute-forced?

Wouldn't it make more sense to generate a Master BTC Private key and determine the random words from that key?

First - I'm not a coder nor do I have any Python/GTK/QT knowledge. Keep this in mind while reading my response. 

I understand that handling several wallets simultaneously would result in a major code change. But putting a extra button (maybe as a drop-down) that lists/loads other known wallets should be done fairly easy.

I don't think two extra buttons ("Send to file" / "Load from file") on the "Send" tab should make the GUI "terribly" complex.

For all the other stuff
Thank you very much.

thank you for the feedback



Several users requested this. I am not convinced that the benefits outweight the cost (increased complexity for the gui),
so my opinion is that it is fine to open several wallets simultaneously (I admit that will not let you merge their histories)

OTOH I will be glad to merge it, if someone comes up with an implementation that is clean and remains optional.
For example the gui could display multi-wallet features only if several wallets are passed with the -w option



it really depends on how it is implemented, but I don't see how to do this without making gui terribly complex.


I agree, I will try to fix those.

I agree

yes, the current code does this.

I've been playing around with various Bitcoin clients (bitcoin-qt, armory, multibit, ...) latlely and so far Electrum seems to be the best choice for my needs.

As I cannot find any roadmap/planed feature list I would like to list some things I'd like to see someday:

* A decent way to handle multiple wallets
From what I've seen up to now you need to restart the Electrum client to switch wallets; I would prefer a way that allows switching wallets within the running client by a mouse click or - even better - Electrum should be able to handle multiple wallets at the same time.

* Offline tx
It should be possible to create ("mktx") the tx_file from within the GUI of the offline client.
Same for the online client - it should be possible to access ("sendtx") the generated  tx_file from with the GUI.
And for the command line I'd love to see a "batch mode" - create a "sendmany" tx_file from a (csv) file.

* Contacts/Addressbook
When adding a new contact why is not possible to set a label for it directly? Right now I've to save and edit the new entry to set a label for it.
Second "issue" with it - when changing a label all views should be adjusted on the fly. Right now the "Histrory" and "Recieve" view will display the old label until the client is restarted.

* Exchange rates
If I don't care about fiat exchange rates it should be possible to disable the lookup.
But if I do care then the rates should always be displayed (on all GUI types, not only on the "light" one).

* The GUI should remember more settings (like preferred UI type, window position and size)
Some of this I've already seen in the latest Git code

I just took a look at the word list that Electrum uses, only because I was interested which kinds of words they use. Then at the end of the list I noticed this comment:

# Note about US patent no 5892470: Here each word does not represent a given digit.
# Instead, the digit represented by a word is variable, it depends on the previous word.

And then I found this:

http://patents.justia.com/1999/05892470.html

Really? This is ridiculous. So if my word list looks like this:

words = [ "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "A", "B", "C", "D", "E", "F" ]

and I use this this list to convert a number I can get in trouble with Microsoft?   

Oops, my bad. This is what I get for counting bits carelessly in my head.
Shorter list is better.

2048 words let you represent 11 bits.  2048 = 2^11.

I'd suggest using a list of 4096 words, each word gives you 12 bits, and so 16 words gives you the 160 (address) + 32 (checksum) bits you need for an address.


The official English scrabble word list has 267751 words, and most of them are pretty obscure.  We'd be very hard pressed to find over a million words that most people would even recognise as words.  I think we should use a relatively small set of very well known, relatively short, each to say, spell, and hear, unambiguous (neither bear nor bare) words.

Note that we only need 160 bits to communicate a bitcoin address.  32 extra bits are used as a checksum, which we should keep.  A list of 16 short words seems acceptable.

The other way to split it would be 12 words of 16 bits each.  2^16 = 65536.  A 65k word list is likely to be uglier though, including obscure words that are harder to spell.  As well as being harder to compile.

Wouldn't the number of words depend on the word list size?

With Electrum the word list size is 1626, which can represent 11 bits. But if you add some words to make 2048 then you could represent 12 bits. So 192 bits would be 16 words.

But if you used a 1048576 size word list you could represent 20 bits, which would be 10 words.

You also need the checksum to ensure that similar sounding words (assuming verbal communication) doesn't fail as not everyone can spell or be sure of word clarity. It's easier to choose 2048 words that don't miscommunicate than 1048576.

All you need to do to establish this is release an official word list so ordinal position is known.

what do you have in mind here? bip 0015?

Wow that would be very cool!

You'd need 15 words to represent a bitcoin address; more if you include a checksum (a very good idea, transpose two words without a checksum and you'd get a "black hole" address).

Creating a secure payment protocol so I can tell people "send payment to [email protected]" and be confident that I'll get the coins is very high on my priority list.

I'm not talking about generating the public address from passphrase, but rather converting the Bitcoin address into a passphrase.   Parse every x characters, convert those characters to a number, and pick that number word from the dictionary.  List all the words you find in order, and you should get a passphrase that represents all the information that is in the public address.

Then, someone else could use the same software to turn that passphrase back into a Bitcoin address to send the passphrase BTC.

It just makes it easier to tell someone an address.  Telling someone ~33 alphanumeric characters over the phone is next to impossible, but 8 words is easy.

I'm not sure that's really possible.  Bitcoin addresses are hashes of public keys, which are created from the private keys.  You can generate the private key from a passphrase (so called 'brain wallets'), and derive the corresponding public keys and addresses from there, but I don't see how you can generate an address or a public key from a passphrase without also having the private key be derivable by everyone who knows the passphrase.

Using FirstBits would be a shorter easier way IMO.

Very cool!  Have you thought about implementing this for public Bitcoin addresses as well?  I think it would be easier to tell someone or remember, "send to 'pain apologize tired bar...' than '1OIh8Eeoighgelni3slghsg...'"