go-ethereum/docs/_doc/Accounts---key-storage-spec...

74 lines
2.8 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
title: Accounts
---
**THIS PAGE IS PARTLY OUTDATED! TODO: REFACTOR OR DELETE**
# 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.
# Background
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.
# Specification
## 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 https://github.com/ethereum/pyethsaletool) 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
0. 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.
## Mist
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
## RPC API
The RPC API must support:
1. The list of accounts is exposed through the eth_accounts API: https://github.com/ethereum/wiki/JSON-RPC#eth_accounts
2. Using any of the available accounts as from/sender with the eth_transact API: https://github.com/ethereum/wiki/JSON-RPC#eth_transact (NOTE: the current API definition on that wiki page does not include a from/sender field!)
## Wallet DAPP
TODO: