Reputed signer reward

This PR adds a block reward to the reputed signers to solve issue #16.

There is a new vote section that has 2 values :

• the number of reputed signers eligible for the reward (among the signers with the highest reputation)

• the amount of the reward (in BKS)

This vote is in the section "signerreward" of the JSON vote. Here's a sample vote:

If the "count" or "amount" value is omitted, null or negative, it counts as a vote for the value in the previous block.

When a value is omitted the vote is still stored in the blockchain (with a negative value), contrary to the expectation that not voting would reduce the blockchain size. The reason is we still have to save somewhere the information indicating whether this vote is included or not. So when the shareholder does vote then there are 2 informations to save (the fact he votes and the vote itself). There are solutions to minimize that but it would be much more efficient to do that on the whole vote and not only to these two small values. So I suggest we think about a more general solution in a future release.

In the GUI, these votes are in the reputation vote dialog. The fields must be left blank to omit voting for a specific value.

The "signerreward" part is selectable in the data feed like the other parts.

The result of the "count" and "amount" votes is calculated by taking the median of the votes in the block itself and its 1999 parents.

The median of an even number of values doesn't really exist by definition. Taking an intermediate value did not seem appropriate here, so I chose to take the higher value when the median is between two different values. For example with 1000 votes for 1 and 1000 votes for 2 the result is 2.

This vote result becomes effective 60 blocks later. Note that when a shareholder does not vote, the value he's voting for is the voted value of the previous block, not the effective value.

There are 2 new RPC to get the result of the signer reward votes:

• getsignerreward which displays the effective signer reward data. Example:

• getsignerrewardvotes which displays the details of the current votes. Example:

• vote is the value voted for

• value is the value used to calculate the result (the same as vote except when it's null)

• count is the number of votes counted

• accumulated_percentage is the accumulated weight of this vote. The first one with an accumulated_percentage strictly above 50% wins.

The vote tab in the GUI displays the current number of eligible signers and the current reward.

To select the signer who will receive the reward for a particular block, we first take all the signers with a positive reputation, sort them by reputation and take as many as the shareholders decided (the number of eligible reputed signers described above). In case of a tie, the ones who received the least rewards in the last 2000 blocks are put in a higher position. If there's still a tie, the one with the highest address (hash) is put above.

The signer (among these eligible signers) who actually receives the reward is the one whose number of rewards received in the last 2000 blocks is the farthest from his expected reward. His expected reward is the number of rewards he would have received in the last 2000 blocks if the rewards were distributed proportionally to the reputation of the eligible signers. In case of a tie, the highest address wins (but the other one is almost guaranteed to win the next time because he will be farther).

The amount of the reward (which was decided by vote) is then included in the CoinStake transaction. It's added as an extra output directly to the address of the signer. When a block is received the client calculates the expected signer address and reward and verifies it's included in the CoinStake in addition to the PoS reward. If it's not, the block is rejected.

All these changes start from protocol 3.1. We discussed about putting them in a 3.2 release but it looks like testing on 3.1 has not started already, so we may just add this feature to 3.1. But it's easy to make it effective on a 3.2 protocol instead if desired.