Suggestion: Ethereum support

[ShockiTV]

Hello,
I want to start discussion about implementing needed changes to have Ethereum support.
There does not need to be too many changes I think.

We should be easily able to reuse whole BIP32 tree with secp256k1 signatures.
Main difference in key/address is that ETH is using 20 char addresses, so there is little change in address generation.

And there is different transaction format.
Ethereum have just 1 unified transaction format with simple structure.

I have already forgot most of my C++ knowledge so I cannot simply update firmware myself.

Regarding transaction costs, I suggest to let that part in caller app responsibility - same as preparing raw transaction object.

Few relevant links to ETH implementation:
JS code of generating address from privkey https://github.com/ConsenSys/eth-lightwallet/blob/master/lib/keystore.js#L149
Whole eth-lightwallet is also using BIP32, so it can be used as reference to simply rewrite these few needed parts to cpp. If it is even needed and we are not doing it on client from received pubkey.

And for example transaction format in cpp https://github.com/ethereum/libethereum/blob/6d65d5d1412013381324826ea583e8b3fa9f5f3c/libethcore/Transaction.cpp#L33
There is sign function on line 111.

After creating and signing transaction which could be all done offline, standard operation would be to transfer it to full node by for example simple RPC call https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_sendrawtransaction

[prusnak]

Does Ethereum use a standard secp256k1 ECC (same as Bitcoin)?
Does Ethereum encourage address reuse or not?

[ShockiTV]

Regarding secp256k1 yes - at least what I picked from source codes and google. I have not found any low level standalone documentation describing details.

Reuse - in current implementation is keystore manager part of full node daemon implementation and it is not using HD, just simple one to one account mapping.

[subtly]

@prusnak Ethereum uses the same library however it uses it in a different way and Ethereum encourages address reuse. I've posted some questions on Ethereum's EIP repository as to whether HD should be adopted or not. I authored the kdf and encryption scheme used by ethereum and I think there's interest in developing an RLP-based kdf scheme rather than BIP32 – this is also helpful for applications where we may want to incorporate large identifiers.

[tscs37]

It should be possible to implement the signature algorithm for Ethereum (secp256k1 ECDSA) on Trezor. If not, contracts could be used to leverage Ethereums EVM for validation within the capabilities of the Trezor Hardware. The later would only require the user to have an Ethereum Account that holds some Ether to pay for the gas of the transaction.

edit: The code from myetherwallet.com could potentially help here, the site offers offline signing of transactions.

[prusnak]

The changes are on the way. Discussion issue here: trezor/trezor-common#11