HomeEIPsNewsletter
EIPsERC-1581
ERC-1581

Non-wallet usage of keys derived from BIP-32 trees

A derivation path structure for BIP32 trees to generate key pairs not meant to hold crypto assets.
StagnantStandards Track: ERC
Created: 2018-11-13
Michele Balistreri (@bitgamma)
Discussions ForumOriginal Proposal LinkEdit
1 min read
Anyone may contribute to propose contents.
Go propose
Video
Anyone may contribute to propose contents.
Go propose
Original

Abstract

BIP32 defines a way to generate hierarchical trees of keys which can be derived from a common master key. BIP32 and BIP44 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 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 recommendations and its amendments for non-Bitcoin usage. 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: TBD

Hardened derivation is used at this level.

Key index

The key index is a field of variable length identifying a specific key. In its simplest case, it is a number from 0 to 2^31-1. If a larger identifier is desired (for example representing a hash or a GUID), the value must be split across several BIP32 nesting levels, most significant bit first and left aligned, bit-padded with 0s if needed. All levels, except the last one must used hardened key derivation. The last level must use public derivation. This means that every level can carry 31-bit of the identifier to represent.

As an example, let's assume we have a key with key type 4' and a key_index representing a 62-bit ID represented as hexadecimal 0x2BCDEFFEDCBAABCD the complete keypath would be m / 43' / 60' / 1581' / 4' / ‭1469833213‬' / ‭1555737549‬ . If you are using random identifiers, it might be convenient to generate a conventional GUID, for example 128-bit just fix the value of the most significant bit of each 32-bit word to 1 for all of them, except the last one which will be 0.

Rationale

The structure proposed above follows the BIP43 generic structure and is similar to the widely adopted BIP44 specification.

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve Ethereum Builders, Scale the Community.
Resources
GitHub
Supported by