[Draft] Frequency Voting

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.

dysconnect 2015-09-10 03:45:13 UTC #60

I’m mixing a few things in this post so please bear with me.

@JordanLee won’t be able to read all posts and think about everything very carefully and I think it is better to let him concentrate on B&C for the moment. While there are some issues with apathetic voters it is not yet a large problem in practice, so we don’t need to have it right now.

On the other hand, I don’t think @nagalim or @creon would be comfortable to leave @JordanLee as the ultimate gatekeeper for NuBits forever. This motion as it stands may not pass because of @JordanLee’s influence, despite the limited involvement he can afford. As the developers won’t have enough time to tend to every potential NuBits improvement, it is time to offload development work and expand development activities within the community. This way we may be able to see progress in things like this.

I suggest that as soon as tier 4 liquidity operations are done we try to establish something like the following workflow to add features to the Nu client:

A motion is put forward to decide whether a feature is good or not (regardless of costs etc.)
Motions to decide compensation
Developer comes forward to implement feature, submit pull request
A motion to suggest those with commit access to review the change
If necessary, a motion to urge accepting the pull request
Custodial grant for developer, if compensation was decided

It’s a lot of voting but depending on realistic circumstances we can trim it down. For example if developers express approval for a change you don’t need 3,4,5 (sometimes even 1); if a member does not want compensation then we can forgo 2,6. If it’s just a bugfix or a non-critical UI change then we might not need voting at all. In reverse, one may put forward motions to block or revert certain features. All the voting is there is to ensure sufficient discussion and consensus is given to community-sourced changes, so it is preferable to only vote when there could be consensus issues.

Just like many opensource projects and Bitcoin, a lot of development is done without explicit and direct compensation from stakeholders; rather they are developed by community members or businesses that depend on the projects. This is also probably the only way to let NuBits an opensource project prosper.

Finally, when the community cannot handle the consensus issues that arise under this kind of development practice, it would be clear that a fork is inevitable.

Also I should note that frequency voting isn’t a formal protocol change so it can’t be directly vetoed, so an enthusiastic community member can just fork the client, implement the feature, and distribute it to those who agree with him.

Nagalim 2015-09-10 05:30:56 UTC #61

Forking or personally distributing would not be possible as this motion very much has to do with the domain ‘nubits.com’ and supplying users with defaults.

bitbucket src/vote.h

Put this stuff at the beginning:

#include < ctime >
srand ((unsigned)time(0));

Assume we read the voting probability from the UI and called it ‘threshold’. Then put this between line 278 and 279:

tester = rand() / RAND_MAX;
if ( tester >= threshold)
------>hashMotion = 0;

The arrow (-------->) represents a tab. How much of the $5,000 does this earn me?