accounts: eip-712 signing for ledger

[MrChico]

Adds a new method SignTypedMessage to the accounts.Wallet type which enables EIP-712 signing with ledgers. For other wallet types it simply falls back to signHash.
Support for 712 style signatures was introduced in v1.5.0 of the ledger firmware, and is specified at https://github.com/LedgerHQ/app-ethereum/blob/master/doc/ethapp.asc#sign-eth-eip-712.
This PR does not expose the SignTypedMessage to clef or anywhere else, I mainly wanted it in ethsign which is really just a cli wrapper around these parts of the geth code.

I don't really know golang so bare with me here... At least I'm able to successfully perform EIP-712 signatures with a ledger with this PR.

[holiman]

I don't know if another API-method is really needed. Clef already supports this, by using the mimetype in SignData to signal that it's 712-type data that's being passed.
So the same mechanism can be used by other backends too.

[MrChico]

The problem is that ledgers won't sign arbitrary data, it will only take the two 32-byte strings messageHash and domainHash. But maybe these could be extracted for the case where the special case where mimetype is typed data?

[holiman]

Isn't that more or less what clef does too:

go-ethereum/signer/core/signed_data.go

Line 335 in 7a3c890

rawData := []byte(fmt.Sprintf("\x19\x01%s%s", string(domainSeparator), string(typedDataHash)))

?

[MrChico]

right, only it would be deconstructing that information, rather than building it.
so I'm thinking to add a special case to SignData of usbwallet/wallet.go which dispatches to driver.SignTypedMessage in the case where

if mimeType == accounts.MimetypeTypedData && data[0] == 25 && data[1] == 1 && len(data) == 66 {

[MrChico]

somthing like this @holiman , what do you think?

[holiman]

This whole clause is more or less a copy-paste of SignTx. Is there any way it can be refactored so they both reuse the whole dance around commsLock and account-lookup and stuff, and not have the same code duplicated?

[MrChico]

Hmm, I'm not sure exactly how to do this, since the defered functions are relative to the scope of the surrounding function. Do you have an idea?

[MrChico]

Thank you @holiman for the review. Besides the refactoring of the commsLock dance, your comments should now be addressed

[holiman]

LGTM