mirror of https://github.com/status-im/EIPs.git
81 lines
3.9 KiB
Markdown
81 lines
3.9 KiB
Markdown
|
---
|
||
|
|
eip: 601
|
||
|
|
title: Ethereum hierarchy for deterministic wallets
|
||
|
|
author: Nick Johnson (@arachnid), Micah Zoltu (@micahzoltu)
|
||
|
|
type: Standards Track
|
||
|
|
category : ERC
|
||
|
|
status: Draft
|
||
|
|
discussions-to: https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742
|
||
|
|
created: 2017-04-13
|
||
|
|
---
|
||
|
|
|
||
|
|
## Abstract
|
||
|
|
This EIP defines a logical hierarchy for deterministic wallets based on [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki), the purpose scheme defined in [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) and eip-draft-ethereum-purpose.
|
||
|
|
|
||
|
|
This EIP is a particular application of eip-draft-ethereum-purpose.
|
||
|
|
|
||
|
|
## Motivation
|
||
|
|
At present, different Ethereum clients and wallets use different derivation paths; a summary of them can be found [here](https://github.com/ethereum/EIPs/issues/84#issuecomment-292324521). Some of these paths violate BIP44, the standard defining derivation paths starting with `m/44'/`. This creates confusion and incompatibility between wallet implementations, in some cases making funds from one wallet inaccessible on another, and in others requiring prompting users manually for a derivation path, which hinders usability.
|
||
|
|
|
||
|
|
Further, BIP44 was designed with UTXO-based blockchains in mind, and is a poor fit for Ethereum, which uses an accounts abstraction instead.
|
||
|
|
|
||
|
|
As an alternative, we propose a deterministic wallet hierarchy better tailored to Ethereum's unique requiremnts.
|
||
|
|
|
||
|
|
## Specification
|
||
|
|
We define the following 4 levels in BIP32 path:
|
||
|
|
|
||
|
|
<pre>
|
||
|
|
m / purpose' / subpurpose' / EIP' / wallet'
|
||
|
|
</pre>
|
||
|
|
|
||
|
|
Apostrophe in the path indicates that BIP32 hardened derivation is used.
|
||
|
|
|
||
|
|
Each level has a special meaning, described in the chapters below.
|
||
|
|
|
||
|
|
### Purpose
|
||
|
|
|
||
|
|
Purpose is a constant set to 43, indicating the key derivation is for a non-bitcoin cryptocurrency.
|
||
|
|
|
||
|
|
Hardened derivation is used at this level.
|
||
|
|
|
||
|
|
### Subpurpose
|
||
|
|
Subpurpose is set to 60, the SLIP-44 code for Ethereum.
|
||
|
|
|
||
|
|
Hardened derivation is used at this level.
|
||
|
|
|
||
|
|
### EIP
|
||
|
|
EIP is set to the EIP number specifying the remainder of the BIP32 derivation path. For paths following this EIP specification, the number assigned to this EIP is used.
|
||
|
|
|
||
|
|
Hardened derivation is used at this level.
|
||
|
|
|
||
|
|
### Wallet
|
||
|
|
This component of the path splits the wallet into different user identities, allowing a single wallet to have multiple public identities.
|
||
|
|
|
||
|
|
Accounts are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.
|
||
|
|
|
||
|
|
Hardened derivation is used at this level.
|
||
|
|
|
||
|
|
Software should prevent a creation of an account if a previous account does not have a transaction history (meaning its address has not been used before).
|
||
|
|
|
||
|
|
Software needs to discover all used accounts after importing the seed from an external source.
|
||
|
|
|
||
|
|
## Rationale
|
||
|
|
The existing convention is to use the 'Ethereum' coin type, leading to paths starting with `m/44'/60'/*`. Because this still assumes a UTXO-based coin, we contend that this is a poor fit, resulting in standardisation, usability, and security compromises. As a result, we are making the above proposal to define an entirely new hierarchy for Ethereum-based chains.
|
||
|
|
|
||
|
|
## Backwards Compatibility
|
||
|
|
The introduction of another derivation path requires existing software to add support for this scheme in addition to any existing schemes. Given the already confused nature of wallet derivation paths in Ethereum, we anticipate this will cause relatively little additional disruption, and has the potential to improve matters significantly in the long run.
|
||
|
|
|
||
|
|
For applications that utilise mnemonics, the authors expect to submit another EIP draft that describes a method for avoiding backwards compatibility concerns when transitioning to this new derivation path.
|
||
|
|
|
||
|
|
## Test Cases
|
||
|
|
TBD
|
||
|
|
|
||
|
|
## Implementation
|
||
|
|
None yet.
|
||
|
|
|
||
|
|
## References
|
||
|
|
[This discussion on derivation paths](https://github.com/ethereum/EIPs/issues/84)
|
||
|
|
|
||
|
|
## Copyright
|
||
|
|
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|