Accounts / key storage specification

This is an attempt to compile a single, written specification from the multiple sources which have so far been used for accounts / key storage specs:

  • Skype calls
  • Skype chats
  • Email conversations
  • Github issues
  • Github pull request comments
  • Github commits
  • Lively in-person discussions in the Amsterdam office.
  • Several past instances of the Amsterdam office whiteboard contents.


Up until Ethereum PoC 8, the Go client has used a single, default key in plaintext on disk for use as wallet and for signing all txs. We want to extend this to have a more generic key storage supporting multiple keys. We also want an “accounts” abstraction over these keys where an account corresponds to a key, and a user can have multiple accounts and be able to send / receive to any of them.

The goal of this is to support better wallet / account functionality both in Mist as well as in DAPPs.


Key Storage

The key storage must support:

  1. Generation of new keys
  2. Deletion of keys.
  3. Multiple, uniquely identifiable keys.
  4. Password protection of keys.
  5. Persistence of keys (e.g. on disk)
  6. Export & Import of keys.
  7. Import of pre-sale keys (generated by NOTE: this is a different import functionality than general import (6)
  8. Proper use of secure cryptography for key generation, password protection, key persistence and export format of keys.
  9. Mechanism for Backing the keys up – maybe automatically

Account Manager

  1. Account == address of an Ethereum account == address of EC public key of EC private key the user controls.

The account manager must support:

  1. Account creation & deletion
  2. Multiple, unique accounts.
  3. Persistence of accounts (e.g. on disk)
  4. An account is mapped to a single key.
  5. The account is identifiable by some public, non-sensitive data. E.g. the Ethereum address of a EC keypair can be used as account identifier / address.


The Mist UI must support:

  1. Creation of a new account.
  2. Display a list of all available accounts (addresses)
  3. Copy-paste of account addresses to easily use when receiving funds.
  4. Choosing one of the available accounts when sending a tx.
  5. Typing password when accessing one of the hot wallet keys
  6. Showing the possible ways to temporarily input wallet keys when needed


The RPC API must support:

  1. The list of accounts is exposed through the eth_accounts API:
  2. Using any of the available accounts as from/sender with the eth_transact API: (NOTE: the current API definition on that wiki page does not include a from/sender field!)

Wallet DAPP