[Draft] Frequency Voting

Nagalim 2015-09-09 16:16:09 UTC #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.

Mark 2015-09-09 19:58:55 UTC #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

Nagalim 2015-09-09 20:07:09 UTC #41

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.

masterOfDisaster 2015-09-09 20:17:35 UTC #42

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

masterOfDisaster 2015-09-09 20:42:36 UTC #44

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

tomjoad 2015-09-09 20:44:32 UTC #45

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.

Nagalim 2015-09-09 20:46:31 UTC #46

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

tomjoad 2015-09-09 20:49:26 UTC #47

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.

Nagalim 2015-09-09 20:50:37 UTC #48

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

Nagalim 2015-09-09 20:52:49 UTC #49

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

Sentinelrv 2015-09-09 20:53:20 UTC #50

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

tomjoad 2015-09-09 20:54:55 UTC #51

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.

Nagalim 2015-09-09 20:56:37 UTC #52

The issue here is that I feel like I have to make something that is 110% complete before the nuteam will even think about looking at it. Yet, once I do that, they shit all over the basic conceptual ideas and send me back to the drawing board, wasting all my time and effort. It’s enough to drive a concerned shareholder away from the community. Oh wait…

Nagalim 2015-09-09 20:58:01 UTC #53

Nagalim:

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

You don’t see that? Its literally the first thing in the post.

tomjoad 2015-09-09 21:00:27 UTC #54

When I did a forced reload of the page your edits appeared, so that was an error on my end with Tor. Yes I see it now.

Nagalim 2015-09-09 22:55:05 UTC #55

Here’s the second motion. The thing is, this one is still very tentative and really I’d want to see the first motion be implemented and have the NuTeam comment before hashing this one.

Motion RIPEMD160 hash: tbc

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

The NuTeam will implement default frequency voting whereby the wallet client hosted on Nubits.com will use frequency voting to automatically start voting by default. Upon minting, the client will look to the past 3000 blocks and begin counting any and all motion votes present. If there is a stretch of 1000 blocks in which a motion receives no votes, the client will ignore any votes for that motion within 1000 blocks of that stretch. The votes for the most recent 1000 blocks will be summed and divided by 1000 to get a percentage. The default voting probability for a given motion is then taken to be equal to that percentage.

The NuTeam will be awarded 250 NBT for doing so.

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

JordanLee 2015-09-10 00:56:26 UTC #56

It wasn’t my intent to make anyone feel like their contribution wasn’t valued. The growth of the network depends on the tenacity of people like @Nagalim. However, it is true that I’m performing triage with the issues I address. B&C Exchange is my primary obligation right now. Despite this, my important and immediate task list for Nu is rather long:

Propose motion regarding the structure of share buybacks.
Faciliate transfer of three liquidity operations roles I am currently performing.
Propose motion trimming NuLagoon compensation for sell side liquidity.
A variety of tasks related to liquidity operations.

I don’t favour frequency voting. It seems like a solution to a problem we don’t have. It is common for uncontroversial motions and grants to get 80% support in a thousand block period. Frequency voting would make it easier for motions and grants to pass. I think the grants and motions that have good support are passing.

About a year ago sigmike and spoke in detail about something quite similar. We spoke about using the blockchain record as a basis for populating votes. We decided against it.

While the specifications are still vague and I haven’t considered what needs to be done in detail, I suspect this would take in the neighbourhood of $5000 to implement. Any directive to implement it should include funding. We are short handed on developers right now, which means it can’t be implemented right away. One of my tasks for B&C is to hire another developer.

[Withdrawn] Reduce mint reward to reduce apathetic voting?

Nagalim 2015-09-10 01:45:27 UTC #57

$5000 to implement a basic random number generator using CPU time as a seed. Creon had this implemented and was ignored. It seems like it’s a pretty good deal to be a Nu dev: just ignore any community development and force everything to go through you, then charge a huge amount of compensation for doing it. Shareholders are forced to pay or let things stagnate.

I give up.

masterOfDisaster 2015-09-10 03:18:53 UTC #58

I realize that you are busy, but as frequency voting has a lot of potential, would you mind elaborating the reasons for not being in favour of this idea?
I agree that it’s not very desperately needed right now, but by the time it would be needed, it might - lacking frequency voting - already be to late to vote for it.

What have been the reasons? @Nagalim’s simulations indicate that security wise Nu doesn’t need to fear drawbacks from frequency voting, but can, depending on the voting apathy, profit big time from it.
Nothing would be worse for Nu than not being able to get votings through because of minter’s voting apathy.

I read this as the development fund is completely dedicated to current development with no buffers left to pay the estimated $5000. Is this correct?

I fully agree!
Nu needs a capable development team (which it has, I think).
But Nu needs the community and people who want to contribute just as much.

Frequency voting and the (un)seeded auction are both contributions from the same person, @Nagalim.
Both have (in my opinion) a very high potential to render an important service to Nu.
Both are being ignored or at least not supported in the way I’d hope for.

…is no reasoning I find cogent.

Summing up:

it’s a solution for a problem Nu might once have (and it’s too late to mitigate it by frequency voting; what if more and more NSR get distributed?).
it’s a solution with no security drawbacks (that I’ve recognized; the simulations indicate there are no relevant drawbacks).
it’s supporting decentralization of voting (in difference to data feeds).

So I wonder, what have been the reasons for you and @sigmike to decide against something similar about which you’ve spoken in detail about a year ago?

[Withdrawn] Reduce mint reward to reduce apathetic voting?

Ben 2015-09-10 03:29:03 UTC #59

Shareholders aren’t forced to do anything. The code is available for anyone to contribute to. Have there been pull requests that have been submitted that were intentionally suppressed? I don’t recall ever seeing them.

If you don’t like Jordan’s quote, and this isn’t something that you’re comfortable coding yourself, please find another one that matches what you think the development effort is worth and let the shareholders know about it.

Where did he have this implemented? In his pool software? I know it wasn’t code that was contributed to the Nu source so it’s not something that was “ready to go” and then ignored or declined. I have no idea how much work would be required to port his implementation to work with Nu, so if you’ve got estimates, I’m sure that shareholders would be interested in learning more.