mirror of https://github.com/status-im/EIPs.git
53 lines
3.0 KiB
Markdown
53 lines
3.0 KiB
Markdown
|
---
|
||
|
|
eip: 1581
|
||
|
|
title: Non-wallet usage of keys derived from BIP-32 trees
|
||
|
|
author: Michele Balistreri (@bitgamma)
|
||
|
|
discussions-to: https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817
|
||
|
|
status: Draft
|
||
|
|
type: Standards Track
|
||
|
|
category: ERC
|
||
|
|
created: 2018-11-13
|
||
|
|
---
|
||
|
|
|
||
|
|
## Simple Summary
|
||
|
|
This EIP describes a derivation path structure for [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) wallets to be used for non-wallet keypairs.
|
||
|
|
|
||
|
|
## Abstract
|
||
|
|
BIP32 defines a way to generate hierarchical trees of keys which can be derived from a common master key. BIP32 and [BIP44](https://https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) defines the usage of these keys as wallets. In this EIP we describe the usage of such keys outside the scope of the blockchain defining a logical tree for key usage which can coexist (and thus share the same master) with existing BIP44 compatible wallets.
|
||
|
|
|
||
|
|
## Motivation
|
||
|
|
Applications interacting with the blockchain often make use of additional, non-blockchain technologies to perform the task they are designed for. For privacy and security sensitive mechanisms, sets of keys are needed. Reusing keys used for wallets can prove to be insecure, while keeping completely independent keys make backup and migration of the full set of credentials more complex. Defining a separate (from BIP44 compliant wallets) derivation branch allows combining the security of independent keys with the convenience of having a single piece of information which needs to be backup or migrated.
|
||
|
|
|
||
|
|
## Specification
|
||
|
|
|
||
|
|
### Path levels
|
||
|
|
We define the following 5 levels in BIP32 path:
|
||
|
|
|
||
|
|
```m / purpose' / coin_type' / subpurpose' / key_type' / key_index```
|
||
|
|
|
||
|
|
Apostrophe in the path indicates that BIP32 hardened derivation is used.
|
||
|
|
|
||
|
|
This structure follows the [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) recommendations and its [amendments for non-Bitcoin usage](https://github.com/bitcoin/bips/pull/523/files). Each level has a special meaning, described in the chapters below.
|
||
|
|
|
||
|
|
### Purpose/Coin Type/Subpurpose
|
||
|
|
This part is constant and set to ```m / 43' / 60' / 1581'```, meaning BIP 43 -> Ethereum -> This EIP.
|
||
|
|
|
||
|
|
All subtrees under this prefix are the scope of this EIP.
|
||
|
|
|
||
|
|
### Key type
|
||
|
|
Describes the purpose for which the key is being used. Key types should be generic. "Instant messaging" is a good example whereas "Whisper" is not. The reason is that you want to be able to use the same identity across different services. Key types are defined at: <to be defined>
|
||
|
|
|
||
|
|
Hardened derivation is used at this level.
|
||
|
|
|
||
|
|
### Key index
|
||
|
|
Keys are numbered from index 0 in sequentially increasing manner.
|
||
|
|
This number is used as child index in BIP32 derivation.
|
||
|
|
|
||
|
|
Public derivation is used at this level.
|
||
|
|
|
||
|
|
## Rationale
|
||
|
|
The structure proposed above follows the BIP43 generic structure and is similar to the widely adopted BIP44 specification.
|
||
|
|
|
||
|
|
## Copyright
|
||
|
|
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|