Implement the verifier monitoring fix (proposed in the white paper addendum)

[sinahab]

To prevent the monitoring attack, “the protocol must prevent Verifiers from revealing which task they are challenging until the final phase of the protocol.” [white paper addendum, page 42].

Verifiers no longer reveal which task they are challenging. They now submit a noisy hash of the taskID, instead of the taskID itself. At a later step in the protocol, they reveal which task they are participating in.

The detailed implementation spec can be found here.

[hswick]

Currently working on an implementation that makes a general challenges mapping in the contract (not per task) it would look like this:

mapping(address => mapping(bytes32 => bytes32)) private challenges;

The only thing is that this solution to the monitoring attack opens up possibility for verifiers to make multiple challenges to same task as all they would need is a different random number being hashed with the task. This could be prevented with a later step, but is it worth it? I can't see any attacks that would be different than a sybil attack also I'm not sure what incentive the verifier would have to make multi challenges for one task. Unless the payout reward was greater...

[hswick]

The other issue is that a verifier's deposit cannot be bonded until they reveal the solution. This means there is no disincentive to not revealing the solution. The consequence of this would be stray challenges in the challenges mapping with no proper way to delete them.

A possible solution is to rethink the entire deposit bonding process...