-
Notifications
You must be signed in to change notification settings - Fork 5.7k
Description
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 commentedon 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 commentedon 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 custompurpose
branch. We wouldn't need to bother with SLIP44 in that case.coder5876 commentedon 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 logicalcoin_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 commentedon 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 commentedon 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 commentedon 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 commentedon 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
axic commentedon 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 commentedon 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 commentedon Feb 5, 2017
SLIP44 has since reserved code 61 for ETC.
MicahZoltu commentedon 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 anotherpurpose
. I fully support picking a new purpose and defining the segments in a way that makes sense for Ethereum. I am wholeheartedly against usingm/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