Ethereum hierarchy for deterministic wallets

[Arachnid]

This EIP defines a logical hierarchy for deterministic wallets based on BIP32, the purpose scheme defined in BIP43 and eip-draft-ethereum-purpose.

This EIP is a particular application of eip-draft-ethereum-purpose.

[MicahZoltu]

What is the purpose of this? What if I create a wallet, post the private key online (perhaps as an accident, as part of troubleshooting, testing, etc.) and then want to create a new (secure) wallet? This rule forces me to submit a transaction (paying gas) just to make that wallet valid so I can move on to getting a new one.

[Arachnid]

Perhaps I should reword this to include the possibility that the same software is aware of a previous use for the wallet?

The issue here is that if users can create wallets arbitrarily 'far away' from the previous one, then anything importing it again later won't be able to find those wallets by enumeration.

[btchip]

Or you might want to add a gap concept similar to BIP 44 here https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit

[Arachnid]

Yes, I'll amend it to add a gap.

[LefterisJP]

Question: So the Purpose is going to be a constant (TBD) that generally defines this as a derivation path following a new hierarchy for Ethereum-based chains, while the Subpurpose will serve as the type/id of the derivation path. Or as the version?

[Arachnid]

That's right. The subpurpose has the same role as the 'purpose' in BIP43/BIP44 paths - it lets us define new sorts of derivation paths with EIPs and without having to consult anyone else.

[LefterisJP]

I see. Thanks. That is clear now. Perhaps add one more sentence there to make it clear to other readers too?

What you just told me or a variaton of thereof would be enough I think.

it lets us define new sorts of derivation paths with EIPs and without having to consult anyone else.

[Arachnid]

I'll do that, thanks.

[jprichardson]

NACK. I don't see the purpose of this. So many wallets already implement other derivation paths in production. Any wallet can also just use any purpose code that doesn't touch the proposed allocated "reserved for SLIPs". Why go against the grain with what wallets are already doing?

[MicahZoltu]

So many wallets already implement other derivation paths in production

@jprichardson The first part of the answer is the pluralization of path in that quote. There is not consistency among wallets and this causes a notable amount of user confusion.

The second part of the answer is that BIP44 doesn't really make sense for Ethereum, and by far the single most common use case for HD wallets is "one mnemonic, many disassociated addresses". This results in most of the BIP44 segments going unused. So standardizing on BIP44 doesn't really make sense here.

The third part of the issue is that it would be nice if we followed BIP43, since that isn't really Bitcoin specific. However, trying to get BIPs pushed through for Ethereum specific things (or even SLIPs) is a non trivial task. The idea here is to stick to BIP43 for general cross-chain compatibility reasons (and it makes sense in Ethereum) but just have one "Ethereum" branch point that allows for all future BIP32 derivation paths in the Ethereum ecosystem to only have to go through the EIP, rather than having to go through the BIP.

[jprichardson]

The second part of the answer is that BIP44 doesn't really make sense for Ethereum, and by far the single most common use case for HD wallets is "one mnemonic, many disassociated addresses". This results in most of the BIP44 segments going unused. So standardizing on BIP44 doesn't really make sense here.

BIP44 can make perfect sense for Ethereum addresses and keys. It already is as we see many wallets already using (I'm well aware of the diversification of paths) it for all sorts blockchain assets.

I can see why someone would want to use BIP43 for other uses cases other than addresses, but BIP44 being an implementation of BIP43, it works well for keys and addresses - my product is proof of that.

[MicahZoltu]

BIP 44: m / purpose' / coin_type' / account' / change / address_index

• purpose: still makes sense (that is BIP43)
• coin_type: makes a little sense... maybe, except adding a new coin type requires going through the SLIP process which is foreign to Ethereum developers. Also, tokens are a dime a dozen on Ethereum and requiring every token get a new entry into SLIP44 is unrealistic. Finally, in Ethereum using different derivation paths for different tokens doesn't make a lot of sense for the average end-user. It is much simpler to put your REP, MKR and ETH all in one wallet. If a user wants, they can create multiple wallets (one for each token type) but there is really no compelling reason to have that be baked in to the simple derivation path (see EIP Ethereum purpose allocation and path scheme for deterministic wallets #600 for how to add more complex derivation paths).
• account: This differs from address_index only in the fact that it is hardened while address_index is not. Functionally, they serve basically the same purpose. It has never been clear to me why you wouldn't just want address_index to be hardened and call it a day. People have made arguments about accounting and such but in reality almost no one ever does this. Unfortunately, the result is that some wallets increment the account and others increment the address_index, leading to failed interop and poor end user experience.
• change: This doesn't make sense in Ethereum, it is a UTXO thing.
• address_index: as discussed above, the usage of this is unclear. Presumably it adds value being un-hardened but for most people it is unnecessary. This is why this EIP combines them into a single hardened incrementing wallet. One can easily create a new derivation path EIP based on EIP Ethereum purpose allocation and path scheme for deterministic wallets #600 that has both hardened and non-hardened. The goal here is to have something that is simple, rather than defaulting to all-the-complexity.

This EIP is meant to define a very simple BIP32 and BIP43 derivation path. The idea is that this is the default for the novice user that doesn't need anything complex and wants their stuff to "just work" in all of the various wallets of the future. This EIP is not attempting to solve all possible HD wallet problems and people are encouraged to create new EIP derivation path schemes based on EIP #600. This particular derivation path will be the default derivation path for EIP #602 mnemonics (which are mnemonics that have derivation path style baked in). The idea is that a user only has to remember their mnemonic, they don't also have to remember their derivation path.

[jprichardson]

Before I dig into the other statements, why would a token have to register a coin_type? Since ERC20 tokens are on Ethereum and require gas and cannot join inputs like the UTXO model, they must reside on an address with Ether. So why would they reside on their own respective address?

[MicahZoltu]

One could argue the same thing for why you should have a separate path segment for coin_type at all. It really doesn't provide any value that I can tell. Sure, it may make less sense for tokens than it does for coins that are used for gas but that doesn't really argue for keeping coin_type for Ethereum derivation paths.

Before you spend too much effort arguing each of the BIP43 segments, keep in mind that this proposal is about simplicity. The first segment is so we are BIP43 compatible. The next segment is so we can have future expansion (EIP #600), and the last (and only segment that is actually part of this EIP) is to allow users multiple addresses per mnemonic. Anything more than that is beyond the scope of this EIP as it increases derivation path complexity.

Note that at least in the Ethereum space, despite everyone using BIP44 and BIP44-like derivation paths none of the segments are used in an interesting way outside of whatever one is indexed. There also isn't consistency with regards to the coin types that are in SLIP44 (Testnet, ETH, ETC) despite them being well defined. This illustrates the need for simplicity in my mind.

[Arachnid]

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

• Frontmatter is now contained between lines with only a triple dash ('---')
• Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---

[MicahZoltu]

@Arachnid I propose we move this to Last Call (after you fixup the necessary changes above).

[Arachnid]

@MicahZoltu Thanks for the ping.

I think this probably needs more discussion, primarily around whether it's likely to get adoption given the prevalence of bitcoin-derived HD paths at the moment.

[MicahZoltu]

In that case, I recommend a discussion link and merge as draft.

[MicahZoltu]

Needs discussion link.

[nicksavers]

Standard_s_ Track

[nicksavers]

I'd be fine with numbering this EIP 601