Reward monitoring service

[rakanalh]

Introduction

A flag --enable-monitoring was introduced into Raiden for the user to specify the intent of whether a monitoring service should be used or not. If monitoring is enabled, when a channel has more than X tokens (capacity) deposited, Raiden automatically sends the latest balance proof to the monitoring service.

Requirements

• The user needs to set the minimum capacity at which at the monitoring service will be used.
• The user needs to set the amount to be paid for the monitoring service, which is going to be used here:
  

  raiden/raiden/raiden_event_handler.py

  Line 564 in b9f2c98

  reward_amount = 0 # FIXME: default reward is 0, should come from elsewhere

• Only If monitoring is enabled, publish balance proof

Expected: End of Feb, 2019.

[LefterisJP]

Part of #216. As defined here: #216 (comment)

Requirement:
* The user needs to set the minimum capacity at which at the monitoring service will be used

Since the price of the underlying token can vary with time see ideas for a price oracle show in the parent issue: here and here

Requirement:
* The user needs to set the amount to be paid for the monitoring service.

I am not sure this is possible. The advertised MS prices are non-binding on their side. So can't guarantee that in any way in the client. Is my understanding correct @palango ?

* How would i know the prices for different MS nodes running? would monitoring services publish their prices over the wire every X period?

The MSes were supposed to advertise their prices in the same broadcast room the clients publish their BPs. Source: The Spec

• What are the default values?

That's too dynamic for a set default. I would say something like the average of the advertised MS prices as seen in the broadcast room with a user configurable +X% of tolerance.

[palango]

The advertised MS prices are non-binding on their side. So can't guarantee that in any way in the client. Is my understanding correct @palango ?

Yes, this is right. Short term there is no way of knowing the current price for a monitor request. Longer term the plan is to add a broadcasted channel in which the MS show their current price, which then can be used by the client to get a better picture.

[LefterisJP]

Yes, this is right. Short term there is no way of knowing the current price for a monitor request.

@palango @rakanalh We discussed this in the OKR meeting yesterday but for the short term the easiest solution would be constant prices for monitoring so that there is no need for the client to learn the price. We know it by default since it will be constant.

Is my understanding of the consensus on the meeting on this correct?

[rakanalh]

Correct, we should use a constant value until MS implements price publishing.

[LefterisJP]

@rakanalh So can you edit the issue's open questions? My comment should answer both.