Skip to content
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

Closed
coder5876 opened this issue Apr 1, 2016 · 28 comments
Closed

Standardizing HD wallet paths for Ethereum Standard Tokens #85

coder5876 opened this issue Apr 1, 2016 · 28 comments
Labels

Comments

@coder5876
Copy link

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
Copy link

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
Copy link

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.

@coder5876
Copy link
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
Copy link

@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
Copy link
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
Copy link
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
Copy link
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
Copy link
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
Copy link

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
Copy link

daira commented Feb 5, 2017

SLIP44 has since reserved code 61 for ETC.

@MicahZoltu
Copy link
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
Copy link

jyap808 commented Jun 19, 2017

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

@fulldecent
Copy link
Contributor

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

@Arachnid
Copy link
Contributor

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

@Arachnid
Copy link
Contributor

I've removed this from the example list.

@chris-shyft
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link

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
Copy link
Contributor

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

@Steve132
Copy link

Steve132 commented Jul 19, 2018 via email

@MicahZoltu
Copy link
Contributor

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
Copy link

[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
Copy link

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
Copy link

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 github-actions bot added the stale label Jan 16, 2022
@github-actions
Copy link

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.

@ethereum ethereum deleted a comment Mar 12, 2022
bumblefudge added a commit to bumblefudge/caip25-proposals that referenced this issue Feb 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests