[Draft] Frequency Voting

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

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 ##=##=##=##=##=##=

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.

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

@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.

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

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

…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?

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.

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

Right? The only member of the nuteam to comment was the marketing rep. Not that I don’t appreciate tom’s input, but someone familiar with the tech would be way more useful here.

1 Like

I think it’s to the point to call it priceless what @creon did for Nu :wink:

…but maybe not the type of attention you are looking for :wink:
It could bring attention to your last statement instead of this ingenious looking draft.
Do you really want to risk that? :bomb:

1 Like

If you want serious input, I would suggest you codify it into a motion with clear, defined requests and technical specifications. I think it’s unfair to suggest that Nu developers must spend their valuable time commenting on every single discussion, especially when we are no longer compensating them for much of their time. Jordan Lee, sigmike, and Giannis’ attention is on B&C Exchange right now.

I coded into a motion complete with compensation this morning. Why is that not good enough?

It’s a best practice to place a draft motion into your original post for easier visibility. I posted a reply to you earlier that apparently was at the same time you posted your motion reply and missed it.

The ironic thing here is that creon already implemented this 6 months ago without motion or compensation and the nuteam ignored it.

1 Like

I also did that this morning. Maybe I should make a hundred duplicate posts so they for sure can’t miss it.

[quote=“Mark, post:40, topic:2509, full:true”]
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.[/quote]

Agreed. One of the reasons @creon left was the development team not taking part in important discussions like this to the point that it felt like they were purposefully ignoring or avoiding them. That helped lead to his negative impression that shareholder input and voting was an illusion of power.

I personally don’t believe that. I believe that the team has their attention split between developing Nu and B&C and they simply have a lack of time available to participate in all the discussions going on. I would hope though that @JordanLee and other team members will read this thread soon and offer their opinions on what has been discussed so far.

It would be a monumental achievement (as long as frequency voting is good for Nu) for a modification of this caliber (that was put forth by a non-team member) to be voted in by shareholders. It would help show that Creon’s assumption about who is really in charge of Nu was wrong and that one of his own ideas was pushed for by a regular shareholder and voted in by the majority. It might even be enough to bring him back.

But first things first, we need feedback from the main development team. Let us know if you believe there are any negatives associated to this that we aren’t thinking about. If there are then we should discuss them and either abandon or modify the proposal. If all are in agreement that this is a good improvement to the current voting system, then we should put it up for a vote.

2 Likes

I don’t see it in [Draft] Frequency Voting? I’m not sure why you are offended by my suggestion, I’m only trying to help.

1 Like