Delegated mining

[area]

Closes #1002

Draft status, as not ready to merge, but after feedback.

Implements what Daniel and I vaguely talked about a while ago. Basically, everything stays the same, but instead of using msg.sender during mining, we instead call a function that either returns msg.sender (i.e. the fallback case should be the existing functionality) or, if a delegation has been awarded to msg.sender, returns the address they are allowed to mine on behalf of.

[kronosapiens]

Interesting, when we discussed this earlier it seemed like we'd need two mappings, but you've done it with one -- using the miner address to look up the delegator during the mining process, and requiring the delegator to pass the mining address explicitly while setting.

[area]

So I've added restrictions that mean that anyone doing any sort of mining must either have tokens staked, or be a delegate miner for another address. If they have both, the former takes priority. This is to avoid the possibility that existed in the original implementation of 'stealing' miners by naming them as your delegate. In this implementation, you still can, but it has no effect (while they have tokens staked). Previously, confirmNewHash could be called by anyone, but now needs to be called by someone with tokens staked.

There were a good number of knock-on effects in the tests, unfortunately, but I think broadly speaking this is better. I don't think it presents a risk of getting in to issues either.

[kronosapiens]

What was the reason for restricting confirmNewHash to staked miners?

[area]

What was the reason for restricting confirmNewHash to staked miners?

So it originally came up because we call getMinerAddress in responsePossible, and the changes I made to getMinerAddress to deal with the griefing angle. I could have solved it by only calling getMinerAddress if we're inside the SUBMITTER_ONLY_WINDOW_DURATION, but realised it makes the mining cycle as a whole slightly more resilient. Picture a scenario where only one person has tokens staked.

1. This person unstakes their tokens
2. Someone calls confirmNewHash
3. The mining cycle is now broken. No-one has had tokens staked since before this cycle started, and so cannot submit the next hash.

By requiring this function call to be made by someone with tokens staked, we guarantee at least one person is able to continue the mining cycle. If the only person with tokens staked is malicious, then they're still able to break things (by unstaking after calling confirmNewHash), but we are now at least not able to get in to such a situation by everyone behaving non-maliciously, which was the case before (both steps 1 and 2 could be done by well-behaving participants).