# Handling challenges by reposting the task

First, each posted task will have at most one solver. For example the solver can just be the first one who posts a solution. If nobody wants to solve, there will be a timeout and the task will be rejected.

Also each solved task will have at most one challenger. If there are no challengers after a timeout, the task will be accepted. Otherwise the tasks will be rejected and reposted when a challenger appears. The solver and challenger will then run the verification game to find out which one will lose the deposit. Part of the deposit of the loser will be given to the winner to cover the cost of verification game.

Assume that the deposit required from solvers and challengers will depend on the cost of the task. For example the deposit could be 100 times the size of the task. When reposting, for example 10% of the deposit could be used to cover the cost of new task, so the required deposit would grow 10x more each round.

If the cost of the task is too large, nobody will be able to afford the deposit. So there has to be some limit. If the cost of the task is larger than limit, it will be rejected. In any case, there will be some limit where if an attacker has enough resources, the system can be compromised (DDoS, hacking nodes, etc.)

## Pros and cons

Pros:
* Task giver won't have to wait for verification game
* There won't be arbitrary number of verifiers to handle

Cons:
* It will not improve security to require larger deposits from challengers. Perhaps the challengers will need loans to afford the deposit.

## Details

The system has following constants:
1. DEPOSIT: how large deposit will be required from solvers and verifiers.
2. COST: cost paid by the task giver.
3. RATIO: What will be awarded from the deposit to opponents.
4. LIMIT: Upper limit for cost of the task.