Skip to content

Standardizing HD wallet paths for Ethereum Standard Tokens #85

@coder5876

Description

@coder5876

After discussions in #84 the community seems to have settled on using the BIP44 standard for Ether HD wallets. The HD path there is

m/44'/60'/a'/0/n

where a denotes the Account and n is the n-th generated address.

For Ethereum Tokens it would make sense IMO to use BIP44 also since it's fundamentally about token transfers. It seems untenable to have each token creator register a different token number (that number is "60" for Ether) in SLIP44 and use the BIP44 directly.

My suggestion is to pick a number representing Ethereum Standard Tokens (I suggest 61 since this is available, and Ether is 60) and register that with SLIP44. Each token is defined by its 160 bit address x. Since each derivation step only has 31 bits we will decompose the address as

x = x0 || x1 || x2 || x3 || x4 || x5

where x0 to x4 are 28 bits and x5 is 20 bits. We now define the derivation path as

m/44'/61'/x0'/x1'/x2'/x3'/x4'/x5'/a'/0/n

for account a and address n. This allows us to have a separate, well-defined path for each token.

Example: We have the Unicorn token 0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7. This would correspond to the HD path

m/44'/61'/89205A3'/A3b2A69'/De6Dbf7'/f01ED13'/B2108B2'/c43e7'/a'/0/n

which in standard decimal notation gives

m/44'/61'/143787427'/171649641'/233233399'/251784467'/186714290'/803815'/a'/0/n

as the final HD path.

Pros: Unambiguous, separate HD path for each token in a token wallet
Cons: Not really BIP44 since BIP44 only has one number between 0 and 2^31 for the coin type.

Discuss! 😃

Activity

niran

niran commented on Apr 1, 2016

@niran

This looks good to me. One path per token is necessary for wallet use cases because detecting the last used address for a path becomes prohibitively difficult in a world of many tokens. This scheme allows all funds to be reliably detected for each token a user or app specifies.

niran

niran commented on Apr 1, 2016

@niran

One objection might be that m/44' paths shouldn't be used for schemes that aren't BIP44-compliant. If that comes up, we can just come up with a custom purpose branch. We wouldn't need to bother with SLIP44 in that case.

coder5876

coder5876 commented on Apr 1, 2016

@coder5876
Author

@niran Yeah, I thought about this too, i.e. using something other than 44' as purpose. Not sure exactly how I feel since technically we're basically collapsing /61'/x0'/x1'/x2'/x3'/x4'/x5' into the one logical coin_type, so it's similar to BIP44. And if we use another number, should we introduce another BIP, like BIP45? It seems strange for something that has nothing to do with Bitcoin anymore...

chrisforrester

chrisforrester commented on Apr 6, 2016

@chrisforrester

@christianlundkvist I like it, it's hyper-rational and as long as the use case is well defined, which is obviously the case for tokens, it makes intuitive sense.

Anthony's conceptual design is to have literally everything branching off of a single mnemonic, I think that's a great idea for a firm foundation and bip 32 was a stroke of genius that will, if extended carefully, cover anything that will come up.

I'm using the concept of "pouches" inside of the main mnemonic->master->purpose node (in this, that would be the "wallet").. I can get behind your scheme here and follow this construction for the token accounts. From what I understand to do this properly we'll need to build an ethereum contract of some sort that can use the same derivation for distribution of tokens, if you have any resources on your end send me a heads up, and we can collaborate in the upcoming weeks and months.

kumavis

kumavis commented on Apr 11, 2016

@kumavis
Member

I think change addresses are still relevant, especially for coin transfers. whether or not that needs to be part of the the derivation path is another question

kumavis

kumavis commented on Apr 11, 2016

@kumavis
Member

if we stray from bip44 and just have a KDF with keypaths, we could use the address of the contract as the standard token pathname

kumavis

kumavis commented on Apr 11, 2016

@kumavis
Member

we keep talking about bip44 but with little mention of the public key derivation feature and whether or not we want to preserve that

axic

axic commented on Apr 26, 2016

@axic
Member

I agree with @niran that it feels a bit forced to use BIP44 (or BIP32 for that matter) with token addresses. One important point which wasn't raised so far is the node discovery ability of BIP44. I think that is one of the reasons it is structured as is.

Fully BIP44 compliant wallets are capable to discover all currently used derived nodes with a simple algorithm from the seed (i.e. someone recovering their wallet don't need to remember anything bar the mnemonic). This is a really good feature from a users' perspective.

This won't be possible when using paths as described above. This may also suggest that BIP32/BIP44 is not the right answer?

psionic81

psionic81 commented on Apr 28, 2016

@psionic81

Maybe the network should support it by design. If we asked a contract to derive the "next address for this user's public address tree", it could return an index instead of a new address, storage would be minimal, and any signed request for an address could still be calculated. That might be way more costly, I still haven't understood the cost balance on large contracts like one that would need to be able to do node derivation.

daira

daira commented on Feb 5, 2017

@daira

SLIP44 has since reserved code 61 for ETC.

MicahZoltu

MicahZoltu commented on Apr 7, 2017

@MicahZoltu
Contributor

I want to reiterate @niran's comment. BIP 43 asserts that the first segment defines what the rest of the path means and BIP 44 defines what the path means if the first segment is 44'. If you are going to do anything other than straight BIP 44 then pick another purpose. I fully support picking a new purpose and defining the segments in a way that makes sense for Ethereum. I am wholeheartedly against using m/44'/* where * is anything other than a BIP 44 path.

The BIP 32 and 43 standards are very amenable to people defining whatever schemes they want and it is well defined how one does this. Please stick with this so when someone is looking at a path it is very clear what it means, without needing to know context like what chain it is for, what tool it is in, what context the author had when they wrote it, etc.

29 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @Arachnid@axic@niran@wanderer@psionic81

        Issue actions

          Standardizing HD wallet paths for Ethereum Standard Tokens · Issue #85 · ethereum/EIPs