Update monitoring service to contract changes #360
Conversation
These contracts are required to put the monitoring and path finding services to work. Merge raiden-network#360 first, to avoid compilation errors.
|
Please also re-enable the MS tests, to make sure things work. E.g. https://github.com/raiden-network/raiden-contracts/blob/master/raiden_contracts/tests/test_monitoring_service.py#L40 (MS tests need some love soon) |
|
@loredanacirstea Should we do this stuff in a development/Ithaca branch for now or is master ok going forward? |
|
@palango , seems |
I think Raiden master is still blocked for red eyes |
|
@palango tl;dr if it is easier for the MS team to make an Ithaca branch to start development, feel free to do so. We can realign after Red Eyes. |
|
My comment here #360 (comment) is wrong. The service contracts can be included in the compiled data (otherwise you cannot use them), and I think we can also deploy them on the test nets. |
|
Let's merge stuff to master then, no need to create more branches. |
These contracts are required to put the monitoring and path finding services to work. Merge raiden-network#360 first, to avoid compilation errors.
Tests are enabled and pass, now. |
The monitoring service contracts did not stay in sync with signature changes in other contracts. This should bring it up to date.
I had to add a channel_identifier parameter to claimReward, as getChannelIdentifier doesn't return a channel id after the settlement.
These contracts are required to put the monitoring and path finding services to work. Merge raiden-network#360 first, to avoid compilation errors.
| @@ -204,9 +204,11 @@ contract MonitoringService is Utils { | |||
| reward_proof_signature | |||
| ); | |||
| TokenNetwork token_network = TokenNetwork(token_network_address); | |||
| uint256 channel_identifier = token_network.getChannelIdentifier(closing_participant, non_closing_participant); | |||
There was a problem hiding this comment.
Consider adding the token_network_address & channel_identifier to the NewBalanceProofReceived event, so you can make a distinction between channels in time (between same participants) and between networks.
You can maybe use the reward_identifier in the event, but then again, you might want to filter all the NewBalanceProofReceived for a specific token network - so this might be over-optimizing.
Can be done in a different PR.
as suggested in raiden-network#360 (comment) .
as suggested in raiden-network#360 (comment) .
The monitoring service contracts did not stay in sync with signature
changes in other contracts. This should bring it up to date.