Possible reply attack problem:

From #134 (comment)
"
Biggest issue: verifyBalanceProof

The balanceProof only consist of: _receiver_address, _open_block_number, _balance. There is no information included on what you are signing, only data. The balanceProof is in this contract already used for 2 things. The sender verifies the new balance and the receiver use this to sign it wants to cooperatively close the channel. This is bad and opens a door for potential replay attacks:

• If any other contract just uses this 3 values for something else (unlikely)
• If there are two channels between address1 and address2 in both directions opened on the same block, they can be used vise versa potential with wrong meaning, if this would be implemented where receiver on the cooperative close is the sender.
• !!At the moment, the close request for cooperative close is just a balanceProof signed by the receiver and the receiving address is the receiver, this message is so not tied to any channel (sender, receiver) because it does not include a sender and can be used to close any channel with the given receiver!!
  fix: Include some kind of message id that encodes the meaning, either cooperativeCloseChannel or balanceProof
• there is another contract deployed which has a channel of the same participants at the same block maybe for example for a different token, the signed messages can be used there.
  fix: include the contract address in the signed message
  "