Deterministic wallets in the reference client

[terrytibbs]

How is the progress on this?

[gmaxwell]

How is the progress on this?

https://en.bitcoin.it/wiki/BIP_0032

There is some active discussion about the exact procedure for generating the master seeds.

I expect it to come in the version after 0.7.0 and potentially off by default there.

[ripper234]

How is the progress on this?

https://en.bitcoin.it/wiki/BIP_0032

There is some active discussion about the exact procedure for generating the master seeds.

I expect it to come in the version after 0.7.0 and potentially off by default there.

Is this a protocol change?
If so, why?
If not, why is this a BIP?
I thought changes to the client that don't affect the Bitcoin protocol don't require BIPs.

[Pieter Wuille]

No it is not a protocol change, but neither are BIP 01, BIP 10, BIP 13, BIP 15, BIP 20, BIP 21 or BIP 22. Just because the most frequently discussed BIPs (BIP12, BIP16, BIP17) are protocol changes, doesn't mean they all are. BIPs are about any standardization that is useful for compatibility between clients. Furthermore, BIP 32 (this one) is informational only.

The reason it is a BIP is because I'd very much like to see it as "the deterministic wallet structure", rather than "the one being implemented in the satoshi client". Especially because deterministic wallets are much more intended to be shared between different systems/nodes, it would also be nice if they could also be shared among different clients.

[Gavin Andresen]

What Pieter said. BIPs are intended to make it easier for different implementations of Bitcoin to inter-operate with each other. The existing network protocol is just one piece of that.

[ripper234]

What Pieter said. BIPs are intended to make it easier for different implementations of Bitcoin to inter-operate with each other. The existing network protocol is just one piece of that.

I see, thanks both for the info.

[justusranvier]

I have a question related to BIP 32.

Deterministic wallets do not require such frequent backups, and elliptic curve mathematics permit schemes where one can calculate the public keys without revealing the private keys.

Could a webserver use this to give a customer an arbitrary number of payment addresses?

Suppose I want to spend BTC10 but no address in my wallet has enough. If I create a single transaction with multiple inputs this will reduce my anonymity. But what if the web server instead gives me a set of parameters to generate as many payment addresses as I need to make sure each transaction (randomly spaced within an X minute interval) has only one input?

The current best practice is to use many different receiving addresses, ideally a different one for each received payment. Perhaps when we exchange payment information what we should be doing instead is giving out unique parameters for generating addresses instead of the addresses themselves.

[jim618]

You can use the public child key derivation function (KDF) to make new Bitcoin addresses on your webserver without the private keys. Thus you can create as many addresses as you like to serve your customers without fear of your private keys been stolen. The customer can also do the address generation.

You could give each customer a new subnode so that the customer can create an unlimited number of addresses for their payments as you suggest yes. You would probably want them to produce addresses (roughly) in order to make your monitoring of the incoming transactions easier.

[justusranvier]

You could give each customer a new subnode so that the customer can create an unlimited number of addresses for their payments as you suggest yes. You would probably want them to produce addresses (roughly) in order to make your monitoring of the incoming transactions easier.

The recipient would know that all the addresses which send bitcoins to the subnode belong to the same person but an outside observer would not, so anonymity would be improved.

[etotheipi]

For reference, Armory wallets are the equivalent of a single "wallet chain" in the BIP 32 diagram.  It has the same properties -- address generation possible from public key and chaincode.  The difference is that Armory wallets must produce addresses in order, whereas BIP 32 can produce any address in the chain with only the root of that chain.  

This design is a lot more flexible than the current Armory wallets:  it gives the user an option to not just have a deterministic wallet, but make new wallets deterministically from the root.   It's a little extra work (interface-wise), but it will be nice to have the option of creating a new node inside your wallet tree (the one you've already backed up on paper in your safe), or start a new tree for a new wallet (so that if one is compromised, the other isn't).

I will be upgrading Armory wallets at the same time that Bitcoin-Qt upgrades to this (or a similar idea).  It will be nice to finally have a natively-compatible wallet algorithm between programs!

[bitcoindaddy]

After reading the document - it appears to use a seed key generated by a random number generator, and NOT A PASSPHRASE which most people seem to expect and want.

[etotheipi]

After reading the document - it appears to use a seed key generated by a random number generator, and NOT A PASSPHRASE which most people seem to expect and want.

Randomized passphrases can be converted to memorable objects via changing the "alphabet". 

Seeds are 16 bytes -- which means 16 base-256 characters.  This can be converted to a passphrase by changing it to base-80,000, where 80,000 is number of words in your dictionary.  Thus you can re-represent a 16-byte seed with approximately 8 such words from your dictionary.    This is what Electrum does.  And I think I'll do something similar in Armory (at the moment, Armory uses 64 bytes for the root key/code, which would be about 30 words, which would be a bit much... so that's why I don't do it right now/yet).

[kuzetsa]

After reading the document - it appears to use a seed key generated by a random number generator, and NOT A PASSPHRASE which most people seem to expect and want.

Randomized passphrases can be converted to memorable objects via changing the "alphabet". 

Seeds are 16 bytes -- which means 16 base-256 characters.  This can be converted to a passphrase by changing it to base-80,000, where 80,000 is number of words in your dictionary.  Thus you can re-represent a 16-byte seed with approximately 8 such words from your dictionary. 

I think you mean exactly 8 words from a 65536 word dictionary
(dictionary words literally indexed 1:1 to 16 bit machine words)

8 words = 128 bits (assuming 65536 possible words)

8 words selected from dictionary size of 80000 would exhaust the 128 bit address space too easily.

assuming you only select 8 words:

4 times as many (8 word) combinations out of 80000 word dictionary compared to the 65536 word ones

... Where did you get the number 80k from anyway?

I have a modest "word game" dictionary sitting around that contains zero hyphenated words, abbreviations, acronyms, or proper nouns.  It also does not contain single-letter words such as "I" ... Just using US english, weighs in at more than double the 80k you listed... was going to feed it into vanitygen but never got around to it.

[etotheipi]

After reading the document - it appears to use a seed key generated by a random number generator, and NOT A PASSPHRASE which most people seem to expect and want.

Randomized passphrases can be converted to memorable objects via changing the "alphabet". 

Seeds are 16 bytes -- which means 16 base-256 characters.  This can be converted to a passphrase by changing it to base-80,000, where 80,000 is number of words in your dictionary.  Thus you can re-represent a 16-byte seed with approximately 8 such words from your dictionary. 

I think you mean exactly 8 words from a 65536 word dictionary
(dictionary words literally indexed 1:1 to 16 bit machine words)

8 words = 128 bits (assuming 65536 possible words)

8 words selected from dictionary size of 80000 would exhaust the 128 bit address space too easily.

assuming you only select 8 words:

4 times as many (8 word) combinations out of 80000 word dictionary compared to the 65536 word ones

... Where did you get the number 80k from anyway?

I have a modest "word game" dictionary sitting around that contains zero hyphenated words, abbreviations, acronyms, or proper nouns.  It also does not contain single-letter words such as "I" ... Just using US english, weighs in at more than double the 80k you listed... was going to feed it into vanitygen but never got around to it.

I used 80k because I heard that's what Electrum used a long time ago.  Maybe it doesn't.  But the example is still valid.  I totally agree that a dictionary of size 2^16 would make a lot more sense...

[jim618]

Ideally the dictionary used would be specified as part of the HD spec.
Then you could type in your eight words in ANY software supporting HD wallets to get your wallet. Full interoperability.

[kuzetsa]

Ideally the dictionary used would be specified as part of the HD spec.
Then you could type in your eight words in ANY software supporting HD wallets to get your wallet. Full interoperability.

I love it.

//update 11:04pm (GMT) Wednesday, July 18, 2012  //

Unfortunately, it's REALLY DIFFICULT to pick words that people would recognize and know how to spell. I decided to only select words that show up in "Enhanced North American Benchmark LExicon" (ENABLE... it's sort of a master dictionary often used for word games like scrabble -- http://google.com/search?q=enable2k)

Cleaned the data with enable2k... which data? The data in question is Licensed under Creative Commons Attribution 3.0 Unported License

I used Google's data for Ngrams / corpus studies:

http://books.google.com/ngrams/datasets

The data came from OCR scans of books found on google books. Be warned. If you try to use their datasets marked as "english", it's full of several non-english words (including french, spanish, italian) and even a misprint or two.

Example of some of the nonsense I found during my last pass of cleaning:

http://pastebin.com/dgZHdarc

Also, there were quite a few things like price lists included in their 1-grams (so like $2.50 and so on)

I'm leaving my most-common 25k word list under Creative Commons Attribution 3.0 Unported License... so if you find a use for this before me, feel free to build on my work... Took me a few days, but here is the list of the most common 25k (twenty five thousand) english (north american... mostly) words which are AT LEAST 5 letters long:

http://pastebin.com/Tvd2nkVJ