Standardizing HD wallet paths for Ethereum Standard Tokens

[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! 😃

[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]

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]

@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]

@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]

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]

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]

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]

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]

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]

SLIP44 has since reserved code 61 for ETC.

[MicahZoltu]

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.

[jyap808]

SLIP44 has reserved code 108 for Ubiq (ticker UBQ).

[fulldecent]

@Arachnid You nominated this as an "EIPs that should be merged". Can you please share your notes on that here?

[Arachnid]

This is referenced as an example EIP from EIP-1. We should either remove it there, or merge it as an official EIP.

[Arachnid]

I've removed this from the example list.

[chris-shyft]

Is there going to be further work on this? reading through all of the comments, if we pick another "Purpose" it could be a fine way to define tokens via addresses. The following however is a potential solution that simply uses indexes:

One of the issues I have is that the address of the token can to be a contract that can be upgraded, but this by definition is more expensive because of the call structure required. So I don't like this method.

#1: Is there a generalized directory system that can be set out automatically to generate the applicable token addresses for erc20 contracts? I'd be fine with a search through the blockchain like etherscan uses, and for each contract that is found (ordering by time of deployment), they have an additional index. bip44 can then be used with an offset (600,000,000 or so.. whatever works really just something that we can preallocate a few million addresses within for future use in token creation.).

first token contract created on ethereum, ordered by time of creation, is 600,000,000, second is 600,000,001, and so on.

first token contract created on ethereum classic, ordered by time of creation, is 610,000,000, second is 610,000,001, and so on.

This would allow for 10 million token contracts to be automatically scanned and appropriately indexed, and incorporated into a master list available to wallets. still following the exact bip44 format.

[Arachnid]

Different wallet addresses for different tokens seems like a solution in search of a problem, to me - there's no real reason to separate them like that, and it leads to issues paying for gas.

[chris-shyft]

Consider it from the wallet developer's point of view.. how do you watch incoming transactions. Having discrete addresses would mean you could bind the addresses themselves to the task, while you'd need a backend infrastructure to watch specific contracts and then disseminate them across the wallet interfaces.

IMO it's where the workload is placed. Unfortunately, there's no fully developed open-source version of something like infura or etherscan at the moment that can watch internal contract events.

[Arachnid]

Consider it from the wallet developer's point of view.. how do you watch incoming transactions. Having discrete addresses would mean you could bind the addresses themselves to the task, while you'd need a backend infrastructure to watch specific contracts and then disseminate them across the wallet interfaces.

I don't follow. How would having a separate address for each token make things any simpler?

[Steve132]

I'm a wallet developer and I think this is a really good idea, but concur STRONGLY with the rest of this thread that a different purpose should be used not 44'

[jamespic]

@chris-shyft Unless I've misunderstood your issue, it's completely possible to monitor internal contract events with open source tools. I just ran the following against my local Parity node to get all ERC20 transfers to my account (0x758e53a86224f6511dbcabd9a364e21b4689653f):

# Transfers to account
curl --data '{"method":"eth_getLogs","params":[{"topics":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef", null, "0x000000000000000000000000758e53a86224f6511dbcabd9a364e21b4689653f"], "fromBlock":"earliest", "toBlock": "latest"}],"id":1, "jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545
# Transfers from account
curl --data '{"method":"eth_getLogs","params":[{"topics":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef", "0x000000000000000000000000758e53a86224f6511dbcabd9a364e21b4689653f", null], "fromBlock":"earliest", "toBlock": "latest"}],"id":1, "jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545

If you need to monitor transactions as they come in, you can use eth_newFilter and eth_getFilterChanges, or use eth_subscribe with WebSockets or IPC on newer clients.

[MicahZoltu]

See #600, #601, and #602 for a more recent set of proposals for HD wallet paths is Ethereum.

[Steve132]

So I'm reading them now and there's like 4 proposals on the table then. What is the final path?

…

On Thu, Jul 19, 2018 at 10:07 AM, Micah Zoltu ***@***.***> wrote: See #600 <#600>, #601 <#601>, and #602 <#602> for a more recent set of proposals for HD wallet paths is Ethereum. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#85 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1kMDdKwIUO3qXHraCELd11ZYti0BZ0ks5uIJKGgaJpZM4H92EX> .

[MicahZoltu]

If you are writing an app today and must choose a path, I recommend m/44'/60'/0'/0/x where x is 0 if you only are generating a single address. Next best option if you want multiple hardened addresses is m/44'/60'/x'/0/0. If you can wait or want to champion a new path then I recommend the #600, #601 and #602 EIPs (they kind of build off each other).

[cbruguera]

[off-topic] Hey @christianlundkvist was there anything done to continue that work on HD derivation for personas/identities on Ethereum? Or is there anywhere else this was (or is) being discussed or detailed? Sounds like an interesting idea to me.

[chris-shyft]

we're probably going to just create something within Shyft that does this correspondence re: Identity, using a different PURPOSE' obviously. I'll send more info when we've concretized our plans.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.