Support personal apis with different keyring backends

[yihuang]

Proposal: Support personal apis

Current behavior: limited supported

Desired behavior: fully support

Use case: web3 api compatibility

Status:

• ImportRawKey, implemented, hangs when running at background with file backend.
• UnlockAccount/LockAccount, not implemented
• ListAccounts, implemented
• SendTransaction/Sign, probably hangs when running at background with file backend

[leejw51crypto]

encrypt , decrypt too
consider embedded database or sqlite

[fedekunze]

What's the status of this? we should prioritize this fix @yihuang @leejw51crypto

[fedekunze]

or maybe @thomas-nguy? this should be supported on mainnet

[thomas-nguy]

linked to this issue

99designs/keyring#85

Or we can just decide to implement it as an additional layer on ethermint?

[fedekunze]

Or we can just decide to implement it as an additional layer on ethermint?

what are you proposing exactly? override the keyring?

[yihuang]

First of all, I think we can only target the file backend? for os backend, is it even possible to have a headless solution?
For the file backend, unlock could be implemented as caching the passphrase or private key in memory.
And in several places, providinging a passphrase to the API through an in-memory buffer so it doesn't read stdin.

[davcrypto]

@tomtau @fedekunze helping on this

[davcrypto]

@fedekunze FilePasswordFunc for file backend has a hard dependency to cosmos-sdk which would be fixed to get input from stdin. Should ethermint has its own keyring config set up and give up this hard dependency?

Or we need to find a way to fire unlock() for file keyring (e.g. clientCtx.Keyring.List() ) once ethermind is started, but it seems hacky