Reputation voting

From the design document:

When a block is minted, the minter may enter up to three upvotes or downvotes, each associated with share address, presumably that of a reputed signer. What the user may place in his client from which these three upvotes or downvotes will be derived is a bit more complex.

The user may place as many pairs of addresses and numbers as they like. This way it is possible for the user to express what the relative reputation of any number of addresses should be. Consider this example user entry as the basis for determining a reputation vote:

8RW7kF2bGhq175ipJWor8aTjM5LBUdZi2D 5
86BqkZdb79W2CT79o84j1pqnhs1R3w3QsB 10
8TgryZQ1dQNJYMjm74K3ajdRnDfsCjh3c3 1
8LMMdCqZYZSj48e8dZLci5kK7h7iMPrJ36 -5

Only three pairs can ever be selected for inclusion in a block, and the quantity of upvote or downvote cannot be specified: it is always understood as one upvote or one downvote. The absolute value of the number beside the share addresses indicate how likely (relatively) each is for inclusion in the block. Whether it is negative or positive corresponds to being an upvote or downvote. So, the first address above is just as likely to be selected for inclusion as the last address, but the first address will always be upvoted and the last address always downvoted. The second address is ten times as likely to be chosen for inclusion as the third address.

Voting would be weighted most heavily toward recent votes. The last 5000 blocks of votes would receive full weight, the next most recent 10000 blocks would receive half weight, and the 20000 before that would receive quarter weight.

@Jordan Lee:

Only three pairs can ever be selected for inclusion in a block

Is it allowed to vote multiple times for the same address? For example someone who is upvoting only one address would actually include that address 3 times.

Voting would be weighted most heavily toward recent votes. The last 5000 blocks of votes would receive full weight, the next most recent 10000 blocks would receive half weight, and the 20000 before that would receive quarter weight.

I don't understand where this weight should be applied. Maybe you want the previous blocks to be scanned for our own votes so that our next vote lean toward our current reputation vote? That looks very complex, and also wrong: if I change my vote, I don't necessarily want my previous votes to affect the new ones.

To select the 3 votes to include I'd just pick them randomly from the reputation vote pool where each address is weighted by the (absolute) associated number.

Currently the vote the user defines is the same as the vote included in the blockchain. With this change, the user now defines a vote that is different than the one he'll include in the blockchain. This has important structural implications.

There are 2 main ways to handle this:

1. We keep using the same structure. We can do this because the 2 votes are actually very similar. The new vote would include a new reputation vote containing pairs of an address and a number. Inside the blockchain this structure would be restricted to having only 3 reputation votes and only -1 or +1 numbers. On the user vote there would not be such a restriction. And we use a new method to generate a blockchain vote from a user vote.
2. We use 2 different structures. The GUI, RPC and data feeds would only affect the user vote structure, and a new method would generate a blockchain vote from an user vote.

Solution 1. is the most simple. It doesn't imply many changes. Solution 2. is cleaner and probably better for the future, as we may have similar situations for which there's no easier solution (for example we once talked about making numerical votes fuzzy to protect privacy, and that may imply extra data like boundaries. We would need to store these values in the user votes, but they don't belong in the blockchain votes).

I'm going to implement solution 1. because it's faster to implement. We would implement solution 2. when we need it or have more time.

Is it allowed to vote multiple times for the same address?

Yes. This will produce the aggregate results we want and it simplifies the code.

Voting would be weighted most heavily toward recent votes. The last 5000 blocks of votes would receive full weight, the next most recent 10000 blocks would receive half weight, and the 20000 before that would receive quarter weight.

I don't understand where this weight should be applied. Maybe you want the previous blocks to be scanned for our own votes so that our next vote lean toward our current reputation vote? That looks very complex, and also wrong: if I change my vote, I don't necessarily want my previous votes to affect the new ones.

To select the 3 votes to include I'd just pick them randomly from the reputation vote pool where each address is weighted by the (absolute) associated number.

---

The weighting rules don't affect voting at all. They only affect the way the reputation of an address is calculated. This will be used to determine who gets the reputed signer block reward.

There are 2 main ways to handle this:

We keep using the same structure. We can do this because the 2 votes are actually very similar. The new vote would include a new reputation vote containing pairs of an address and a number. Inside the blockchain this structure would be restricted to having only 3 reputation votes and only -1 or +1 numbers. On the user vote there would not be such a restriction. And we use a new method to generate a blockchain vote from a user vote.

I agree option 1 is the right way to go.

The weighting rules don't affect voting at all.

Ok I removed them from the initial post and will discuss that in #16.

Actually I put it back. We should probably add an RPC to get the current reputation scores, and probably something in the GUI.

I'm going to implement solution 1. because it's faster to implement. We would implement solution 2. when we need it or have more time.

Actually another problem came up (see issue #18) that will require handling protocol and user votes differently like in solution 2. But I'll keep the simple scheme from solution 1 (using the same "reputation vote" structure for both votes).

Solution proposed in pull request #14.