EIPs/EIPS/eip-601.md
lightclient 3194278525
Switch validator to eipv (#2860)
* switch to eipv

* fix

* fix

* 1153 remove trailing whitespace

* remove file name checks

* 615 remo whitespace before comma

* 884 remove extra single-quotes

* 1337 remove whitespace before comma

* 1057 remove extra spaces after comma

* 2470 update created date to Y/M/D format

* 1078 update required eips to be in ascending order

* 2477 update required eips to be in ascending order

* 1271 remove extra whitespace

* 2767 required eipupdated to be in ascending order

* 2525 update created date to Y/M/D format

* 2458 remove trailing whitespace

* 1884 remove trailing whitespace

* 712 authors should be on a single line

* 601 remove extra whitespace

* 1485 remove unneeded parentheses

* 634 remove trailing whitespace

* 2657 update discussions-to to correct spelling

* 2009 remove trailing whitespace

* 998 required eips updated to be in ascending order

* 1186 remove trailing whitespace

* 1470 remove extra whitespace

* 1895 update created date to Y/M/D format

* 2747 remove extra whitespace

* 1613 remove leading whitespace

* 1571 can'have both handle and email in author field

* 1191 remove trailing whitespace

* 1973 remove trailing whitespace

* 196 don't wrap title field

* 1679 required eips must be in ascending order

* 1620 author can't have both handle and email

* 197 don't line wrap title field

* 2378 remove extra newline

* 1355 author can't have both handle and email

* 698 update created date to Y/M/D format

* 2193 required eips must be in ascending order

* 214 remove extra info after author email

* use v0.0.3 of eipv

* 1 remove malformed field

* bump eipv to v0.0.4

* cache eipv build

* 1485 remove extra author info

* 2771 removing extra whitespaces
2020-08-10 11:18:25 -05:00

3.9 KiB

eip title author type category status discussions-to created
601 Ethereum hierarchy for deterministic wallets Nick Johnson (@arachnid), Micah Zoltu (@micahzoltu) Standards Track ERC Final https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742 2017-04-13

Abstract

This EIP defines a logical hierarchy for deterministic wallets based on BIP32, the purpose scheme defined in BIP43 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. 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:

m / purpose' / subpurpose' / EIP' / wallet'

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

Copyright and related rights waived via CC0.