Get rid of local signing

[LefterisJP]

Related to #1400 (comment)

At the moment we always sign transactions locally on Raiden and send it to the ethereum node for transmission. That is introducing some friction on determining the order of transactions and on handling the possibility of other applications using the same private key that Raiden uses.

The alternative would be to simply delegate the transaction signing to the ethereum node and use something like eth_sendTransaction in order to send Transactions to the node and let it do the nonce management.

This issue needs discussion.

We need to evaluate the reason we use local signing, compare with letting the ethereum node do the signing and nonce management and then if it makes sense to change the current behaviour to do so.

[ulope]

Reasons for local signing I can remember:

• Running eth nodes with permanently unlocked accounts is insecure
• Interactive confirmation (e.g. Parity signer) is undesirable for non-dev / unattended deployments
• I can't quite remember why we didn't (couldn't?) use web3.personal.unlockAccount()

[LefterisJP]

Running eth nodes with permanently unlocked accounts is insecure

We can also just use the personal_sendTransaction (the name may be a tad bit different, will look it up) which unlocks the account only for that one transaction that you try to send.

[andrevmatos]

I don't think running unlocked eth node is more insecure than opening the key by ourselves. It may need additional setup step (to block external connections, etc), but I think it may have some advantages:

• we may/should rely on standard interfaces for signing, e.g. eth_sendTransaction, eth_sign and eth_signTypedData (when stable)
• we may rely on the eth node to give wider key support
• related to above, it'd be nice to keep the possibility of using hardware keys. Currently, signing is interactive, but with e.g. Trezor T/Core supporting custom firmwares, it could emerge an option to unlock/authorize once, auto-sign in the future, and would be nice if we support standard signing interfaces, so geth/parity/Metamask could be used to interface with those hardwallets
• if the user wishes, it may allow full interactive signing. It may not be practical for a full node, but the light-clients sharing libs could make good use of it

Obs: personal_unlockAccount isn't available in Parity out-of-the-box, but can be activated by enabling personal in Parity's interface, or unlocking directly on parity command-line. Anyway, it's a nice interface for recurrent signatures which we should make use of.

[LefterisJP]

but can be activated by enabling

Not a problem. For geth it's there I think. We can have specific requirements for using a local ethereum node.

[pcppcp]

here are some scenarios where local signatures make sense

• light raiden client that connects to a public geth node
• some sort of DMZ separation - raiden clients on one network, geth node on an isolated network interfacing the chain, allowing only selected clients to access its RPC interface. Because eth node is facing the internet, it shouldn't be trusted.
• company that provides raiden-in-a-cloud. You don't want to run separate geth for each customer, but having single point where the keys for different nodes are unlocked is also out of question.

[andrevmatos]

@pcppcp Yes, these are valid use cases. But, if we stick with the eth-node/web3 signature interfaces, couldn't we support them through some kind of middleware, like Metamask (which is, by itself a middleware to e.g. infura) or ApeWorX/web3.py#649 , while still fully supporting node-side signatures?

[pcppcp]

@andrevmatos yeah, I like the idea of web3 middleware, I hope they merge it soon. MS currently uses a rather ugly contract wrapper to sign locally.

[palango]

If we think that the middleware is the best way to go forward we should maybe look into finishing the web3 PR ourselves. The majority seems to be done.

[andrevmatos]

@palango agree, adding that we need/should also add at least eth_sign support to it too, and this path also involves finishing web3.py raiden migration #1293 #1019