EthereumHDKDF

There&＃39;s a long discussion about using BIP32 (the Bitcoin HD wallet KDF) and BIP44 (the KDF path standard) for Ethereum.

It was raised that perhaps a different scheme could be useful.

How Bitcoin HD wallets work?

1. A mnemonic (i.e. a list of memorable words) is generated (see BIP39)

2. This mnemonic is converted to a seed using PBKDF2 (see BIP39)

3. The seed is used to generate root private key using SHA512-HMAC (see BIP32)

4. From this root key, sub keys are derived (see BIP32), where the node layout is set by BIP44

BIP32

What makes BIP32 useful:

• in use for multiple years and was subject to more scrutiny
• multiple implementations in multiple languages exist (with varying level of quality)
• multiple hardware solutions implement it
• can support a wallet, where the same nodes are used as keys for Bitcoin and Ethereum (bad idea)

Where BIP32 may be lacking:

• it doesn&＃39;t magically make Ethereum work with those BIP32 implementations (including hardware wallets). They are pretty much catered for Bitcoin only.
• the path structure is very rigid (each path element is practically limited to 31 bits), fitting in long data (such as token addresses) feels a bit clumsy
• it is battle tested, but that doesn&＃39;t mean it couldn&＃39;t be improved (see this recent proposal for improving edge-cases)

Ethereum scheme

Requirements:

1. be compatible with the Bitcoin scheme as much as possible

2. use native Ethereum methods where possible

3. support per-contract (token) layouts

4. should it support the ability for outsiders to derive public keys?

5. should have a deterministic way to solve the node skipping issue (where a path would result in an invalid private key)

6. should it have a way for node discovery? (see BIP44)

Derivation paths

• /general/
• /contract//
• /token//

Where  is a counter starting from 0.

Simple derivation

It should share the same seed as output by BIP39. This means the same seed can be shared by BIP32 and this scheme.

A given private key can be calculated via: privKey &＃61; sha3(rlp([seed, [path array]]))

This doesn&＃39;t satisfy points 4), 5) and 6) of the requirements.

A possible solution for 5) is to have a nonce to increment as the last parameter of the RLP if an invalid node is derived.

A possible solution for 4) is to move the nonce outside the RLP and use it via the public key derivation used in BIP32.

A wild idea for node discovery:

1. Store the derived paths in a text format (maybe JSON?) and encrypt it with a specific node

2. Store the encrypted list in IPFS/Swarm

3. Have a "namereg" to map the IPFS/Swarm address to an address of another specific node