New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardizing HD wallet paths for Ethereum Standard Tokens #85

Open
christianlundkvist opened this Issue Apr 1, 2016 · 24 comments

Comments

Projects
None yet
@christianlundkvist

christianlundkvist commented Apr 1, 2016

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 comment has been minimized.

niran commented Apr 1, 2016

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

This comment has been minimized.

niran commented Apr 1, 2016

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.

@christianlundkvist

This comment has been minimized.

christianlundkvist commented Apr 1, 2016

@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

This comment has been minimized.

chrisforrester commented Apr 6, 2016

@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

This comment has been minimized.

Member

kumavis commented Apr 11, 2016

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

This comment has been minimized.

Member

kumavis commented Apr 11, 2016

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

This comment has been minimized.

Member

kumavis commented Apr 11, 2016

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

@wanderer wanderer added the ERC label Apr 14, 2016

@axic

This comment has been minimized.

Member

axic commented Apr 26, 2016

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

This comment has been minimized.

psionic81 commented Apr 28, 2016

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

This comment has been minimized.

daira commented Feb 5, 2017

SLIP44 has since reserved code 61 for ETC.

@MicahZoltu

This comment has been minimized.

Contributor

MicahZoltu commented Apr 7, 2017

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

This comment has been minimized.

jyap808 commented Jun 19, 2017

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

@hiddentao hiddentao referenced this issue Aug 16, 2017

Closed

Mnemonic generation and HD wallet generation #3

0 of 5 tasks complete
@fulldecent

This comment has been minimized.

Contributor

fulldecent commented Mar 22, 2018

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

@Arachnid

This comment has been minimized.

Collaborator

Arachnid commented Mar 23, 2018

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

@Arachnid Arachnid removed the needs-merge label Mar 23, 2018

@Arachnid

This comment has been minimized.

Collaborator

Arachnid commented Mar 23, 2018

I've removed this from the example list.

@chris-shyft

This comment has been minimized.

chris-shyft commented Mar 23, 2018

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

This comment has been minimized.

Collaborator

Arachnid commented Mar 23, 2018

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

This comment has been minimized.

chris-shyft commented Mar 28, 2018

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

This comment has been minimized.

Collaborator

Arachnid commented Mar 28, 2018

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

This comment has been minimized.

Steve132 commented Apr 7, 2018

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

This comment has been minimized.

jamespic commented Jul 18, 2018

@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

This comment has been minimized.

Contributor

MicahZoltu commented Jul 19, 2018

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

@Steve132

This comment has been minimized.

Steve132 commented Jul 19, 2018

@MicahZoltu

This comment has been minimized.

Contributor

MicahZoltu commented Jul 21, 2018

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).

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