[Draft] Frequency Voting

Development Protocol
#21

I can definitely vote and rally for frequency voting but I prefer to also add a few (cheap) safeguards. For example, an apathetic client would not vote for a motion for the first 1000 blocks that the motion was seen, which has a small impact on the convergence time but gives some robustness without bloating the chain.

Although the formal 50% threshold of motion success is quite rigid, the consensus establishment and conflict resolution behind voting is somewhat softer, in that it is more flexible and is also hazardous beyond whether a motion succeeds with exactly 50%. So I won’t worry too much about these protocol-wise drawbacks as long as it is kept small. I also feel it is a good price to pay for avoiding the centralization of datafeeds.

2 Likes
#22

We can also implement frequency voting on datafeeds such that someone is 30% cryptog, 30% cybnate and 40% apathetic. However, that would be a later implementation.

Glad you’re onboard! I’m not sure what you mean by a 1000 block wait to start so let’s spell it out:

Block 0 is the first block to vote for a motion. Clearly, you don’t want apathetic voting to start till block 1000. However, when apathetic voting starts does it average blocks 0 through 1000 in which there is any % support, or blocks -999 through 0, which contains the minimum support: exactly 0.1%?

#23

I think I want apathetic voters to not vote in 0-999, but will cast a vote depending on the average votes over 0-999.

So let’s say there are 90% apathetic voters and consider a motion with 50% consent. For blocks 0-999, the percentage of votes would be 5%. Then at block 1000, apathetic voters will start voting, and the probability that a vote is cast is going to be about 0.050.9 + 0.50.1 = 9.5%.

1 Like
#24

Totally. Like you show, it will cause a discontinuity in apathetic voter rates, but that’s not really an issue. I’ll put it in the code tomorrow and post some updated images. However, just thinking about it I think it should strictly decrease the voting rate until convergence is reached. Interestingly enough, such a modification would make the apathetic voting simulation insensitive to the ‘initial’ parameter, and therefore hostile takeovers of the system lasting less than 1000 blocks.

1 Like
#25

@dysconnect here’s the issue: all that is required with the original idea is for the wallet to look at the past 1000 blocks. If we want them to ignore a motion for a period after it sees it, they have to remember all motions that have ever been on the blockchain. I’m not sure how much memory that would take, but it doesn’t seem like the best idea to me.

Can you think of a way to feasibly implement such a feature? Would we need to just say ‘if you see it on the blockchain while running, remember it but don’t act on it until 1,000 blocks later’? That would result in a smaller apathetic participation rate by an unknown amount, especially for a longer block time like peercoin.

Oh! We could say something like: If there is a stretch of 1000 blocks without the motion, then wait 1000 blocks to begin counting after seeing the motion. That would require tracking of 3000 blocks I think, which is pretty reasonable.

#26

Frequency voting is an interesting idea but likely quite complex to institute in practice. If simplicity in the protocol is our ultimate goal to ensure reliable performance and security, there is a much easier solution, and that is simply removing the 40 NSR minting reward.

The network right now offers minting incentives to two groups of users: those who care primarily about financial rewards (“Incentive A”), and those who care about influencing the network through voting (“Incentive B”). The majority of shareholders will gather utility from both of those outcomes, but will always prefer one or the other if receiving a reward required only one response.

We currently offer data feed functionality to limit the damage caused by minters who only care about Incentive A. It allows those minters to collect their financial reward without influencing the network through apathetic voting.

We don’t currently offer any functionality to limit the damage caused by minters who only care about Incentive B, because there is no damage possible. They are guaranteed a 40 NSR reward by default when they mint and vote.

I would argue that because a second incentive (Incentive B) exists on the Nu network that is very, very likely powerful enough to incentivize a secure number of minters to participate, that Incentive A is unneeded. I would even argue that the presence of financial minting rewards encourages centralization in voting.

To illustrate this, I have a simple example. Let’s pretend the network has ten minters, four of whom primarily mint because of Incentive A, and six of whom primarily mint because of Incentive B. For simplicity’s sake, each group would stop minting if their primary incentive no longer existed. All minters have an equal amount of 1,000,000 NSR.

MINTER - MOTIVATION

M1 - Incentive A
M2 - Incentive A
M3 - Incentive A
M4 - Incentive A
M5 - Incentive B
M6 - Incentive B
M7 - Incentive B
M8 - Incentive B
M9 - Incentive B
M10 - Incentive B

Because Incentive A minters only mint because of financial rewards, let’s pretend that {M1-M3} are using Cybnate’s data feed service, and M4 is using Cryptog’s data feed service. The data feed providers are likely Incentive B types who value voting participation, and so M5 is Cybnate herself and M6 is Cryptog himself. {M7-M10} vote according to their own beliefs as Incentive B minters.

That means that there are 10,000,000 NSR minting/voting, with only 6 unique voting patterns:

M1 - Votes Cybnate
M2 - Votes Cybnate
M3 - Votes Cybnate
M4 - Votes Cryptog
M5 - Votes Cybnate
M6 - Votes Cryptog
M7 - Votes Independent 1
M8 - Votes Independent 2
M9 - Votes Independent 3
M10 - Votes Independent 4

If we set the minting reward to 0 NSR, {M1-M4} will elect not to mint. In that scenario, only 6,000,000 NSR would be minting and voting, but there would still be 6 independent voting patterns. In this case no data feed is given disproportionate centralized influence simply because it captures the apathetic Incentive A user vote. In terms of voting robustness and decentralization, the important number is not the total number of NSR minting – as long as some minimum threshold of minters exists, as I think it would for Incentive B – but the total number of independent voting patterns per NSR.

So, setting the mint reward to 0 NSR feels less centralized to me because of this. Data feeds partially exist out of necessity because we don’t want apathetic voters to cripple the network. Removing the mint reward solves that problem and prevents the data feed centralization in votes from occurring. While it wouldn’t influence market cap, a 0 NSR reward would also increase the share price of NSR if the supply was static or declining too.

I hope most minters realize by now that the mint “reward” is nothing more than an inflationary penalty on non-minters, so removing the minting reward should be less controversial on the Nu network because another incentive to mint exists.

I’m interested in feedback on this. It solves the issues that frequency voting attempts to remedy, while reducing voting centralization and requiring no additional protocol complexity.

4 Likes
[Withdrawn] Reduce mint reward to reduce apathetic voting?
#27

I propose something without any protocol changes and you propose something that fundamentally alters the PoS and somehow that is less complex?

Frequency voting involves no protocol changes at all. It is merely a change in default settings of the wallet client.

Having additional minters on the system that don’t vote add to the PoS security, we want to milk them for security while ignoring them for voting. Frequency voting, a much simpler solution than changing protocol, achieves this.

Basically, what about the people who don’t want to figure anything out, data feeds or voting or anything. They know peercoin and will only mint if there is reward (incentive A) but won’t deal with data feed stuff. Cause in reality it’s like this:

M1-200 Incentive A
M201-1000 Incentive B

After setting mint to 0:
M1-100 Cybnate
M101-200 Cryptog
M201-1000 Independent

Instead, using frequency voting:
M1-200 Doing what M201-1000 do
M201-1000 Independent

With data feeds you force people to pick sides. With frequency voting and data feeds people are free to ‘abstain’.

1 Like
#28

Here’s how frequency voting works:

  1. Be a minter, doing your minting thing, on default, just downloaded blockchain and dropped some nsr in, don’t care, the world is my oyster.
  2. Time to mint, look at the last 1000 blocks. Sum the votes for each motion mentioned in those 1000 blocks.
  3. For each motion, roll a random integer between 1 and 1000. If it’s less than the sum, vote for the motion. If it’s more than the sum, don’t vote for the motion.
  4. Dance the happy dance of frequency voting.
2 Likes
#29

I don’t follow. Incentive A voters in my example above will not vote at all in the absence of a NSR minting reward. In your example, M1-200 would stop voting and M201-1000 would continue. My argument is that removing the apathetic vote in this way increases the diversity of voting patterns across a set amount of NSR, because data feeds are nothing more than a centralizing factor on voting diversity per NSR. My argument also relies on the assumption that Incentive B provides enough minters to surpass some minimum level required for sufficient network security, which I think it would.

Either way, I didn’t intend to hijack your thread. I noticed you were discussing the minimization of apathetic voting above and thought my idea was relevant to the discussion. I agree frequency voting is an interesting concept.

1 Like
#30

Oh, ok. So they would also stop securing the network, correct?

Yah, I’m not willing to gamble on that. Having apathetic voters roll a die seems like a much simpler and secure way to do it.

No such thing. A network can always be more secure.

Would you expect the mint difficulty to drop precipitously when there are no motions or grants to vote on? That way people have more voting later. I sure would, anyway.

1 Like
#31

Frequency voting would also be more anonymous as random addresses will vote for random things. The patterns can only be seen when looking at the whole network, so connecting individual voters to pseudonyms becomes much more difficult.

Seriously, why have we not implemented this yet? It’s almost literally just a die roll.

1 Like
#32

Motion RIPEMD160 hash: tbc

=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=

The NuTeam will implement frequency voting whereby the wallet client hosted on Nubits.com contains an additional column when voting on motions. This column will be referred to in this motion as ‘voting probability’ and have user-defined real numbers between 0 and 1 and will be defaulted to zero. Upon minting, a wallet client will roll a random number between 0 and 1 for each motion and if that number is greater than the user-defined voting probability it will vote for that motion. Otherwise, it will not vote for that motion. Standard voting rules still apply, including a maximum number of motions voted for per block. When that number is exceeded preference is given to motions with a higher voting probability.

The NuTeam will be awarded 50 NBT for doing so.

=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=

#33

I wouldn’t. Voting for “zero” outcomes is still helpful for the network and protects the value of my NuShares. I would be aware that continuing to vote for 0% parking rates would be helpful to the network when demand is static or rising, and I would be aware that voting for no custodial grants is helpful to the network to prevent attackers from trying to grant themselves NBT or NSR.

#34

I would hold my votes until I had something to vote on. If rates are where I want them and nothing I care about is up, I would put my money on exchange to try to make more of it.

I would not vote for any protocol change of that magnitude without proper analysis.

What I am proposing in this thread is not a protocol change and has had ample analysis. It’s simple, effective, and has a landscape of additional benefits for making a voting neural network.

Your proposal necessarily decreases PoS security. Mine necessarily increases it by providing an ‘abstain’ vote for those who want to help secure without voting.

For example, I’ve shown that frequency voting is viable at over 90% apathy. With a 0 mint reward model we would lose that 90% entirely. Can our network take a 10 fold reduction in minters and still be secure? If not, then the 0 mint reward model is inferior to the frequency voting model.

1 Like
#35

@JordanLee @sigmike @erasmospunk @Ben @CoinGame @pennybreaker
Do y’all need more than 50 NBT? How much do you need to implement a simple random number generator? You can use CPU time as the seed.

#36

That is not necessarily what other NSR holders do.
Looking at the current difficulty

nud getinfo | grep blocks
    "blocks" : 520060,

 nud getdifficulty
{
[...]
    "proof-of-stake" : 0.00027709,
[...]
}

I think it wouldn’t hurt if more NSR holders minted.
If even some are withholding their minting because they don’t want to vote, don’t want to register data feeds and don’t want to hurt votings by voting against all the frequency voting is beneficial.
Data feeds equal centralization. Even with good will of the data feed providers, there are limits that can be bypassed with frequency voting, e.g.:

This is in no way to criticize @cryptog! I’m very glad that he is one of the pioneers providing data feeds and I’m sure that vacation is well-deserved.
But it shows another limit of data feeds. Unattended (even if only temporarily) data feeds potentially carry a danger.
I expect that most people who registered that feed wait until the vacation is over.
That is two weeks without updates of voting behaviour.
Nu will not perish because if this.
And I believe data feeds are better than having no data feeds at all.
But from what I learned in this thread I think frequency voting is superior to data feeds.

In fact there haven’t been any scenarios outlined so far, in which frequency voting would be worse than what we have now - or did I miss something?
In the worst case it doesn’t help, because all NSR holders mint and care for the votes.
In the normal case it helps, because we can’t be sure that not a few people are in the category “don’t vote, because to lazy for configuring votes and don’t want to hurt the voting process”.

2 Likes
#37

I’ve shown this only happens at apathy percentages near 99.99%, at which point our current voting system would be well beyond inviable and a zero mint system would be completely insecure.

1 Like
#38

…I bet if the voting percentage has dropped to 0.01% the Nu network is done - with or without frequency voting.
Would it really be worse with frequency voting?
As I consider an environment with 99.99% apathy stone-dead, it can barely get worse with frequency voting :wink:

… I hear voices whispering about the “Nu Zombie network” - should I listen to them?

#39

I tend to agree, but I would not make such a bold statement when proposing a motion this general (I intend frequency voting to be applied to all peershares and peercoin as well). The thing that really gets me is that this model can work even at 99.99%; not well, the statistical abberations are intense, but it still converges and works. That means with frequency voting we could still function at 0.01% voting. Seriously, as amazing as that sounds, Nu could still somewhat function as intended at that percentage with frequency voting. Anything more than 0.01% of network participation is just icing on the cake.

Of course, if an attacker goes and buys up 0.01% of the network when there’s only 0.01% participation, they can now pass any motion they want simply because no one is there to tell them no. Mind you, that same thing could happen in any of the other ideas suggested (including the 0 mint reward concept). That’s where data feeds come in, to mitigate that risk. This plan seriously is as absolutely long term as we can get. Think about it: we can eventually make a system that guesses what your votes will be based on previous votes you’ve made and how much you’ve agreed with datafeeds and majority votes in the past. Then, if you feel like it, you can tell it if it’s right or wrong. This reduces the burden of voting by an amount that no shareholder has fully grasped, including me.

#40

25 days and lack of any comments or arguments for or against from development team. It makes me bad impression and I think this disappoints @creon and we lost developer with many fresh ideas who did a lot for Nu and even without any charge.

Edit:typo

2 Likes