Go-ethereum: Please add geth account export <address>

[stephantual]

So that it's easy to export encrypted keys, without having to guess which folder they are in (if you run both cpp and go clients, it quickly gets confusing)

Thank you

[tgerring]

Current solution way to export keys is with https://github.com/ethereum/gethkey

[obscuren]

geth account export <address> <location> should be an alias for cp -r $ETHFOLDER/keys/<account> <location>

[zelig]

It is not clear if you are requesting export of unencrypted private key or not.
Export of unencrypted key is not supported on purpose after deliberating the risk to end users. @obscuren is there a need to revise that decision?
Export of encrypted key will not be supported, since there is no need to replicate the OS copy command, the location of keyfile and the possibility to transfer it across versions and (go) nodes should be well documented.

[obscuren]

Literally what it says. An alias for copying the directory (i.e. "export" the encrypted key)

[zelig]

ok finally settled on not replicating OS copy instead try improve documentation on keyfile portability and locations.
Closing.

[donpdonp]

One point of confusion as a geth newcomer, is 'geth account import' wants a raw privkey. If only the encrypted form/json blob is available, when would import be useful?

[obscuren]

Other clients do allow private key exports. For security reasons we don't.

[zelig]

@donpdonp the encrypted form can simply be copied no need to import it. Please see

It is safe to transfer the entire directory or the individual keys therein between ethereum nodes. Note that in case you are adding keys to your node from a different node, the order of accounts may change. So make sure you do not rely or change the index in your scripts or code snippets.

https://github.com/ethereum/go-ethereum/wiki/Managing-your-accounts

[donpdonp]

It looks like import is there purely for legacy reasons. Thanks for the info.

[mariusnita]

Seems like a liability to not allow export of private key. Users can't have their keys in raw form to put in cold storage or paper wallet or whatever, independent of the implementation of any ethereum client.

[jslim18]

Yea, that's pretty make no sense, isn't it?

[IvanAnishchuk]

I believe the main need for it is to maintain client-independent backups (definitely encrypted, but most probably in a user-friendly way so that privkey can be than imported into any client, possibly cold storage/paper wallet kind of thing). Also simply moving to some client would usually require an unencrypted key. I suppose it is for advanced users only who understand that they shouldn't leave the key lying around so it might have some additional ways to discourage users from using it plus security measures to thwart potential malware (although malware wouldn't have a problem anyway once it gains access to data file and password) and a couple of warnings on top but it would be extremely useful for those few who need it. Because I've actually seen advice on the web to upload wallet data to some third-party sites for decryption and that is a security disaster or third-party decryption apps which are less so but still are not audited by wide community so who knows.

[mariusnita]

One way to get around this is by making a public/private key pair via some other means -- for example MyEtherWallet, then importing into geth. So that way you already have your private key independent of whether geth lets you export it.

[lispczz]

By the way, Parity has a API called exportAccount that can be used to export keystores.
I write a nodejs service to facilitate exporting private key from a parity full node.
https://github.com/lispczz/parity-dumpprivkey