Incentivization, Spam Protection and Validation in Whisper
=========================================================

# OKRs

- P0. Improve decentralization, including light client support
- P2. 50 users running Status nodes

# Problems

- how to convince community to run Status nodes?
- one idea is that people would do that voluntarily
- they would not in the long-term
- some would do that in order to be independent, for example running a Mail Server to avoid giving up some metadata
- provide incentivization layer, i.e. pay SNT for running nodes
- how much SNT?
- we can assume a single node on Digital Ocean which costs around $10/mo
- SNT value should cover that
- it must be easy
- clear step-by-step instruction
- for example, how to run a Status node on Ubuntu and Digital Ocean
- clear instruction how they can earn SNT
- it requires registering and managing their nodes
- DApp?
- how to monitor if registered nodes are good and provide quality service?
- one can register a node but it can work poorly
- for example, Mail Server can be often down and fail to deliver all historic messages
- payment must depend on the service quality
- validators are a must ???
- who would run validators?
- what would be incentivization for doing that?
- stake and slash
- providers would need to stake some SNT in order to register their nodes
- if they provide good service, their stake is safe and they earn SNT
- if the service quality is bad they do not earn SNT and their stake might be slashed
- how to decide when stake should be slashed?
- slashed stake, in some %, goes to a validator
- we would need to provide validators
- how to prevent from abusing being a validator?
- I can run a lot of validators and try to attack nodes with DoS in order to get their stake
- how validator can prove that service's quality is bad?
- MailServer -- it fails to deliver historic message
- one more problem is that MailServer can limit peers they accept; how a validator can not be blocked?
- Whisper -- ???
- should validator also stake SNT?
- can a Status node validate validator and slash its stake? :D
- how and for what should the Status app users pay?
- for Mail Servers,
- each Mail Server may have a different price and capabilities (one can store messages for 1 month and another one for 1 year)
- for message passing by Whisper nodes ???
- should the payment depend on the number of messages
- OR the time the node uses connection slots
- for bumping PoW of their messages ???
- is it possible? It was mentioned long time ago during a call with Whisper co-author
- how should they pay?
- stake and token burning?
- there is an EIP for subscriptions payment

# PoC 1

Above, we distinguished two groups of users: service providers and users.

As we don't want to put any more impediments on users and we want to fulfill our quarter objectives, we should focus on service providers.

## Objectives of PoC 1

- it's possible for non-core-contributors to run a Mail Server and register it in Status Mail Server Registry
- registration requires a stake in SNT
- non-core-contributors can run validators which will verify if registered Mail Servers provide a good quality service
- figure out how to do that
- there is pool of SNT from which Mail Server providers are paid if they provide a good quality service
- similar incentive as 1MM for work done through SOB

# Thoughs on proof-of-custody inspired solution

1. We established that a MailServer needs to send commitments for envelopes it is going to store
- commitment will contain envelope's hash and a signature of the hash
2. Validator submits a challenge on-chain,
3. Challange requires data from which a message hash is recreated: `hash=H(data, ttl, topic, expiry, nonce); if ecRecover(hash, sig) == msg.address`, the challenge is resolved successfully,
5. Reputation needs to be somehow calculated
- commitments with larger envelopes (data field) will results in a larger reputation value
- a higher number of commitments also increases a raputation score
- obviously, failing a challenge decreases a reputation score

## Attack vectors

1. Validator can send a lot of challenges in order to get rid of compeeting MailServers,
- if a challenge is resolved successfully, validator's stake is slashed
2. MailServer can trick a validator to challenge it,
- it's hard to see any gain for MailServer
- MailServer must pay a tx fee to resolve a challenge which is much higher than making a challenge; it won't get validator's stake
3. It is impossible to resolve a challenge successfully because of huge `data` value in the envelope
- MailServer must be careful about commitments it broadcasts
- check Optimizations section below

## Optimizations

1. Consider removing `data` from the calculations. This will require providing an additional hash `hash=H(H(data), ttl, topic, expiry, nonce)` in the commitment, however, it will reduce the cost of resolving a challenge.

# Resources

1. https://gladius.io/pdf/gladius-whitepaper.pdf
2. https://distributedlab.com/whitepaper/ProofOfcustody.pdf
3. https://github.com/AdamColton/trustGraph