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

Ethereum purpose allocation and path scheme for deterministic wallets #600

Merged
merged 7 commits into from
Mar 18, 2019
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 61 additions & 0 deletions eip-draft-ethereum-purpose.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
## Preamble

EIP: <to be assigned>
Title: Ethereum purpose allocation for Deterministic Wallets
Author: Nick Johnson <[email protected]>, Micah Zoltu
Type: Standard Track
Category : ERC
Status: Draft
Created: 2017-04-13
Replaces: [84](https://github.com/ethereum/EIPs/issues/84)


## Abstract
This EIP defines a logical hierarchy for deterministic wallets based on [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) and the purpose scheme defined in [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki).

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:

<pre>
m / purpose' / subpurpose' / *
</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 a value to be determined; the authors of this EIP are still engaged in the standards process to obtain assignment of a 'purpose' field.

The purpose field indicates that the subtree of this node is used according to this specification.

Hardened derivation is used at this level.

### Subpurpose
Subpurpose 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the already confused nature of wallet derivation paths in Ethereum, we anticipate this will cause relatively little additional disruption

This sentence does not exactly instill me with a sense of tranquility, it more reminds me how many very difficult UX problems we still have to solve.

That said, I agree, we've already "bought in" to this confusing paradigm, and isolating accounts per-purpose is a standard evolution that we've been looking forward to for a long time.

These changes are modest, and I think easily agreeable to any client developers currently supporting the BIP39 standards.


## 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/).