update SPEC

[pcppcp]

SPEC should slowly iterate towards more technical document, including details on i.e. message format and interfaces used.

[LefterisJP]

I am removing this from the spec:

Implementation options
-----------------------

* Broadcast: All monitoring services listen on a global shared chat room for balance proofs that act as requests to monitor a given channel. This is the version we will implement.
* Selective: Users select monitoring services explicitly from a registry or similar and directly provide balance proofs to them

Also the Selective spec since it's not going to get implemented:

Spec “selective”
================
Client will select a service he trusts and will submit the balance proof to it.

General requirements
--------------------
MS SHOULD register themselves in [TBD] (list in a smart contract w/ required deposit for a registration? Also announce fee type and amount via this channel) 

Users wishing for a specific channel to be monitored choose one or more MS from the registry. (Could be automated through the raiden node) (Selecting a MS not in the registry is also in theory possible)

Users are RECOMMENDED to register BPs with multiple MS for increased availability and robustness.

The users provide updated BP to the selected MS via i.e. REST-API

Once the MS accepted a BP via the API it MUST monitor the associated channel until close.

MS MUST listen for the `ChannelClosed` event for channels that it is monitoring. 

Once a `ChannelClosed` event is seen the MS MUST verify that the channel’s balance matches the latest BP it accepted. If the balances do not match the MS MUST submit that BP to the channel’s `updateTransfer` method.

Choosing a service to use

A smart contract will maintain a list of trusted services. To prevent griefing attacks, MS that wants to be included in the list will register itself by depositing a reasonable amount of ETH. Another option is a community-curated list. 

Raiden node will then pick one or more MS from the list, depending on the required degree of redundancy.

Pros and cons
-------------

Pros:

* Better Privacy of Raiden nodes
* Fewer scalability concerns

Cons:

* More complicated Implementation
* Problem of selecting partner(s) to trust
* Easier to DDoS the MS

Fees/Rewards structure
----------------------

Subscription based
''''''''''''''''''
A subscription based payments might be useful with this approach. A time-based or membership fee can be used.

Payment per BP submitted
''''''''''''''''''''''''
A small fee is collected for every BP submit. As the fees will probably be too low to be sent as an on-chain transaction, a Raiden (or uRaiden) payment channel between client and service should be used.

Reward for successful update of a closing channel
'''''''''''''''''''''''''''''''''''''''''''''''''
A smart contract may release the reward to the last participant who submitted the BP. See discussion in Broadcast spec.

Also the problems to consider.

Problems to consider
====================

Griefing Attack against Monitoring Service (e.g. to distract competitors)
-------------------------------------------------------------------------
An adversary would not provide recent BPs and the MS would try to update the Closing with an outdated BP, which would not be accepted in the end, i.e. would not be eligible for the reward but would have TX cost. 

Multiple Reward Claiming attack against User
--------------------------------------------
If rewards could be claimed before settlement of a channel, then monitoring services could update the closing channel multiple times with old BPs and claim multiple rewards. 

Blockchain spamming
-------------------
Multiple MS may submit the Challenge Period Update, but only one of them will correct the reward, making the other transactions useless. 

Chain congestion
----------------
If there are too many transaction pending to be mined, Challenge Period Update may not be mined in time. 

Gas price
---------
If gas price is too high, and reward to be collected is too low, MS may choose not to perform the update.

Recovery of the reward by the Raiden Client
-------------------------------------------
What will happen if the Raiden node comes back online? Should it be possible to get the monitoring service fee back?

Challenge Period Update of the channel with no reward attached
--------------------------------------------------------------
It should be possible to submit BP with no reward for doing the Challenge Period Update. 

Trust of services
-----------------
How will monitoring services gain trust? Will there eventually be a third-party service to provide statistics of servers’ uptime?

These should be separate issues in this repo and should be addressed one by one and the spec properly updated.

[LefterisJP]

also removed the notes observaitons:

Notes/observations
------------------
The NettingChannelContract/Library as it is now doesn’t allow more than one updated BP to be submitted. 
The contract also doesn’t check if the updated BP is newer than the already provided one
How will raiden nodes specify/deposit the monitoring fee? How will it be collected?

A scheme to prevent unnecessary simultaneous updates needs to exist. Options:
MS chose an order amongst themselves

Pro:

* Easy to understand

Con:

* Complex to implement
* Prone to communications failure
* A deterministic algorithm assigns time slots within the Challenge period where MS are allowed to submit BPs (needs to tie in with the reward SC)

Pro:

* (Relatively) easy to implement

Con:

* Constraints the available time for providing BPs per MS which could lead to missed / failed updates
* Increased complexity in reward SC
* Variant of the above: As the end of the Challenge period approaches the algorithm allows increasing numbers of MSs to act simultaneously. This increases the chances of a successful update while preventing unnecessary ones in the common case.
* ‘Auction’ approach: the reward decreases depending on time/number of participants
* Mempool monitoring - if there’s multiple txs performing Closing Update, it’s less likely the MS is going to succeed

[LefterisJP]

@pcppcp Please make separate issues for all the open problems and address them one by one.

[LefterisJP]

I consider this closed as we got any outstanding spec issues documented in the spec repo itself.