Decide on rewards & incentive structure for scrypt verification

[sinahab]

There is no jackpot in the current scrypt-interactive design; verifiers do not expect to earn rewards at equilibrium, as claimants will not submit incorrect claims.

To keep things simple in this proof-of-concept, we can assume that verifiers are altruistic. This means that: we need to run multiple independent verifier clients at different geographies.

Furthermore, we need to decide how to price the deposit required for being a claimant or verifier. This brings up multiple points:

a) the deposit should be partly burned (e.g. 60% burned, 40% transferred from loser of verification game to the winner). This is to prevent an attack where someone keeps challenging their own claim, indefinitely DoS'ing the system, without losing any deposits.

b) what should the actual deposit value be? A good candidate is deposit == 2 x (gas costs), or perhaps even more. This makes it costly for someone to submit bogus claims, while also remunerating verifiers.

c) we need to protect against an attack, described as follows: the attacker knows the total amount of deposits the altruistic verifiers have available. Therefore, it creates enough claims to bond all these deposits, and then some more. These extra claims will go through unchallenged. The solution to this is to limit the number of parallel claims.

[teutsch]

Why 60%?

[hswick]

This should be addressed by @sinahab's recent protocol work