Warn about using same private key from other applications and remove nonce management

[LefterisJP]

From this comment.

Either we assume that we share the privatekey or not:

• if we don't share it, then the nonce update is useless: The running Raiden node is the only one sending transactions with that key, therefor the only node changing the nonce, so the local nonce is always valid.
  • assuming the ethereum node puts transactions in pending faster than Raiden restarts.
• if we do share, then there will be races where two nodes send the different transactions with the same nonce, only updating the nonce without fixing and resending the transactions is not sufficient. At the best case scenario, the retry logic would also fix the transaction, but then either:
• the two nodes deadlock each other and waste ether, because one will try to overwrite the other transaction and needs to pay more for the gas
• the node which sent the rejected transaction accepts that it lost the race and sends a new transaction with a fresher nonce. This is IMO just too annoying, the effort is not worth and would be better to just /not/ use local signing.

TODOs:

• Provide a warning message to the user in the start of the raiden node, letting him know that he should not use the private key used for raiden in anything else as long as the raiden node is running.
• Remove the code updating nonce for a given interval. The nonce must be updated from the chain at the start.

[hackaugusto]

Did I understand correctly that you want to disallow using the same private key in 2 local running raiden nodes?

How would we do that? I can only think about asking the user to not reuse the same account.

And with that assumption throw away the nonce management?

Yeah, I would just remove it

[LefterisJP]

How would we do that? I can only think about asking the user to not reuse the same accoun

• Each running raiden node should either put a lock file inside ~/.raiden with the name being the address the private key corresponds to or ... write that to one common lock file.

• Each running raiden node would first check the above mentioned file/files and if the key requested for unlocking is contained in that lock file then it would exit with a message: Another raiden node is running in this machine with the account XXX unlocked or a stale lock file exists at PATH.

[hackaugusto]

That is not really what I was thinking about, it only a fixes the problem for different Raiden process, what about another app?

Btw, we are locking the database, and use a directory per address, so that is already the case

[ulope]

We already have a lock file for the DB:

raiden/raiden/raiden_service.py

Line 239 in 4992c10

self.db_lock = filelock.FileLock(self.lock_file)

And since the DB path is scoped to the eth address that is effectively a lock for the privkey as well.

[ulope]

Ah Augusto was faster :)

[LefterisJP]

Hmm you are both correct. The privkey lock is already there via the DB lock. So removing this part from the issue. And as Augusto pointed out that does not rule out other apps from doing the same. We should only mention it to them to not use the same privatekey from other apps.

Will edit the description.

[hackaugusto]

nonce management was removed by #2064
account ownership was done by #1838