Prevent BalanceProof replay attacks for different Registries and Ethereum networks

[konradkonrad]

With #287 we implement a replay attack mitigation scheme, that relies on the state of one (and only one) raiden network. We assume, that a channel will have a limited number of messages per lifetime and apply a starting nonce scheme, based on the block number.

Since anyone can start a new raiden network by just deploying another instance of the Registry contract, there is no guarantee that Alice and Bob will never have a channel for the same asset opened at the same block number in two raiden networks R and R' (which would lead to the same nonce ranges being valid in channel AB(R) and AB(R')).

Level One State Specific Replay Attack Mitigation

A state specific replay attack mitigation scheme would (instead of relying on the opening block number) use something specific to the channel contract instance, e.g. hashing the channel contract address into each signature.

Note, that this potentially still leaves replay attack vectors open for raiden instances on different blockchains (i.e. testnet vs mainnet), across forks, etc...

Level Two State Specific Replay Attack Mitigation

For further hardening, the opening party could provide a blockchain specific piece of information (e.g. genesis block hash/fork block hash) that would become part of the channel data and should be concatenated with the channel contract address for signatures.

Whether we need this second level of replay protection should be discussed.

See also #93

[LefterisJP]

Let's also add to the discussion of this issue whether we would like to have this as part of the MVP or if the nonce ranges are enough for it.

[hackaugusto]

Note: Added a test case for a replay attack using the same Registry but different Token that should be fixed with this issue.

[LefterisJP]

Related to this issue is the reported issue for lack of a check of the recipient address in the contract (#601) and its solution of adding said check (#602).

As specified in this ticket though there also the scenario of different token networks, different raiden networks, or even different blockchains/forks. Instead of introducing specific checks for all we can handle them by implementing the "Level One State Specific Replay Attack Mitigation" and "Level Two State Specific Replay Attack Mitigation" respectively.