DCIPs/EIPS/eip-600.md

2.9 KiB

eip title author type category status discussions-to created
600 Ethereum purpose allocation 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 this proposed change to BIP43.

This EIP is a particular application of BIP43.

Motivation

Because Ethereum is based on account balances rather than UTXO, the hierarchy defined by BIP44 is poorly suited. As a result, several competing derivation path strategies have sprung up for deterministic wallets, resulting in inter-client incompatibility. This BIP seeks to provide a path to standardise this in a fashion better suited to Ethereum's unique requirements.

Specification

We define the following 2 levels in BIP32 path:

m / purpose' / subpurpose' / EIP'

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 set to 43, as documented in this proposed change to BIP43.

The purpose field indicates that this path 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. This permits new Ethereum-focused applications of deterministic wallets without needing to interface with the BIP process.

Hardened derivation is used at this level.

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.

Test Cases

TBD

Implementation

None yet.

References

This discussion on derivation paths

Copyright and related rights waived via CC0.