"account" RPC API over IPC for standalone signer.

[frozeman]

Abstract

This is the API for a standalone signer daemon, which will handle private keys and signing and deliver support for HD and hardware wallets.
This daemon will have its own IPC connection and will be separate from any running node.

NOTE This is API v 1.0 for a signer daemon without UI!

Connection

JSON RPC 2.0 over IPC.

This signer should open its own IPC connection.
e.g. on ~/Library/Ethereum/signer.ipc

Binary flags

--datadir /path/to/keystore

API

IN PROGRESS

account_list ( )
> [{
        type: "account |hd|ledger|trezor",
        url: "...",
        accounts: ['0x234567','0x2134567'] // maybe HD path?
    }, {
      ...
    }]

account_new ( string: password) 
> {
        id: 0,
        type: "account|hd|ledger|trezor",
        url: "...",
        accounts: ['0x234567'] // only one for "normal" accounts
    }

account_newHDWallet ( string: newPassword ) 
> {
        id: 0,
        type: "account|hd|ledger|trezor",
        url: "...",
        mnemonic: "hello world iam here ...",
        accounts: ['0x234567'] // first account generated
    }

account_newHDWallet ( string: newPassword ) 
> {
        id: 0,
        type: "account|hd|ledger|trezor",
        url: "...",
        mnemonic: "hello world iam here ...",
        accounts: ['0x234567'] // first account generated
    }

account_getHDWalletAddress ( string: id, number: index?? ) 
> 0x1234567654321234567...

account_export ( string: address|id|publicKey)  // works also of HD wallets
> { web3 keystore json }

account_import ( Object: web3 keystore json) 
>  {
        id: 0,
        type: "account|hd|ledger|trezor",
        url: "...",
        mnemonic: "hello world iam here ...",
        accounts: ['0x234567', '0x234567', '0x234567']
    }

account_importPrivateKey (string privateKey)
> {
        id: 0,
        url: "...",
        type: "account|hd|ledger|trezor",
        accounts: ['0x234567']
    }

account_signTransaction (object: txObject, array: JSONInterface, string: password)
> 0x123456789876543212345678..
// OR
> {
   hash: '0x234567890',
   r: '0x456789',
   s: '0x234678',
   v: '0x02',
   signature: '0x1234567654321234567' // full RLP encoded signature, passable to eth_sendRawTransaction
}

account_sign (string: message, array: JSONInterface, string: password)
> 0x123456789876543212345678..
// OR
> {
   message: 'Hello',
   hash: '0x234567890',
   r: '0x456789',
   s: '0x234678',
   v: '0x02',
   signature: '0x1234567654321234567' // full signature, passable to personal_ecRecover
}

account_recover (string/Object: RLPencodedsig|ObjectWithSignatureValues)
> '0x23456789876543212' // Ethereum address

// Is the below needed, or can "is transaction" be auto detected in "personal_recover"

account_recoverTransaction (string/Object: RLPencodedsig|ObjectWithSignatureValues)
> '0x23456789876543212' // Ethereum address

account_unlock (string: address|id|publicKey, string: password)
> true

account_lock (string: address|id|publicKey)
> true

Addition we could add support for subscriptions for key adding etc.

[frozeman]

I would actually propose too to change the namespace from personal to account, as this is more specific.

Then we can also make some functions shorter like personal_unlockAccount to account_unlock

[danfinlay]

I like the idea of exposing some methods for requesting the signer create new accounts, but I don't like the idea of the signer returning private information in response to that.

Imagine a website, asking "create a new account for use with us", and then handing them the private keys. That doesn't sound very secure.

I like your idea about an account namespace, but since personal is established, to avoid breaking APIs, I'd prefer either:

• Adding it in addition to personal.
• Leaving it to the abstraction layer. So maybe web3 exposes this as account, but the underlying provider still uses personal.

[frozeman]

Ok maybe to clarify. This Proposal was created after a debate in the go team about adding a separate signer instance, with its own IPC connection.

This will be additional to the personal endpoint (which might be deprecated at some point) and will not be part of the node, but a separate process with separate IPC connection. Dapps like IN Mist won't have access to this API, but Dapps LIKE Mist will.
This will be the main signer for native dapps to use, and receiving private information will only be available on functions where you need to provide a password ;)

So This wont be part of default web3, as Dapps can't connect to this IPC endpoint.

[holiman]

Why would these be needed:

• account_getHDWalletMnemonic ( string: address|id|publicKey, string: password )
• account_importPrivateKey (string privateKey)
• ....

Generally, I don't understand why we'd design the API to let the caller handle a lot of sensitive stuff. I'd want the signer to take on the security responsibilities, so that callers can concentrate on things not related to private keys, passwords, signing. That means that the signer should expose methods like

• account_signTransaction (object: txObject, string: password, bool: returnRLPEncoded, object: optional_ABI) - to enable sign-what-you-see
• account_restoreHDWallet() - no arguments, the signer will commence the restoration flow and ask the user for input.

[frozeman]

As we extensively discussed the signer wont have any UI for now, we can always change the API later once a signer with UI comes around.

As long as that is not the case the native dapp need to be able to present the mnemonic phrase to the user.
We also should be aware that this is not a user interface, but a developer API.
So we surely need ways to export and import, retrieve keys, etc. It also should look the Mist/custom dapp way, as long as we don't have a signer UI.

Besides when generating there always need to be a password send along to get this secrets like privatekys, so its not that they are exposed over that API for everybody.

[bas-vk]

In the long run I agree with @holiman that the signer should handle all sensitive data even if that means that Mist has to make sacrifices to its user experience.

The protocol will be json rpc 2.0 with the same conventions as the rpc interface has (e.g. hex encoding, data must be a multiple of 2)? The examples json message are not valid json rpc 2.0 messages.

What is the purpose of the key id? We have something for non-hardware devices. But I'm not sure if hardware tokens also have something like that. Maybe just remove it?

I also think that the singer should have support for notifications. Hardware tokens can be plugged in/out at will and the singer should be able to inform its clients of such events.

account_signTransaction: maybe the api should not accept returnRLPEncoded and always return an RLP encoded transaction that can be send with eth_sendRawTransaction. I'm also thinking if this method should accept an argument to indicate which signing algorithm should be used. Recently eip 155 was introduced that prevents replay attacks. Some hardware tokens might not have support for it, or only after a particular firmware version. It would be nice if the client has the ability to specify a signing algorithm version and get an error if the signer was not able to meet these requirements.

[frozeman]

@bas-vk

• all HEX?
  I would say no, as there is no reason why to format things to HEX, the main reason for that on the ethereum RPC are numbers, and even that we could have handled better i guess.
  So all should be in its normal format, but obviously RLP encoded signatures are hex

• The Id is mainly there to reference accounts - as an extra identifier

• notifications are cool, tho the client don't needs to be aware of possible hardware wallet keys anyway. So they need to be persistent, even if the hardware wallet is not plugged (as i currently see it, we soundly use such notification probably)

• account_export gives an array or json object back, the native dapp has to decide how to return this to the user, e.g. file etc. The signer shouldn't write backups to disk in this function.

• Concerning backuping all (making address|id|publicKey optional), i agree

• concerning signTransaction: The returnRLPEncoded is needed, as we want to be able to return signature, and RLP encoded signatures. The main reason is to be able to verify signature in solidity, which wants the plain signatures, rather than RLP encoded.

• I disagree with the EIP flag, i would always use EIP 155. If hardware wallets don't support it, then thats not really of concern to the dapp, but the user has to know about it, when buying the device.
  the dapp will only forward it to sendRawTransaction in either case.