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
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…
2 Likes
You don’t see that? Its literally the first thing in the post.
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.
2 Likes
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 ##=##=##=##=##=##=
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.
$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.
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?
2 Likes
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.
1 Like
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.
4 Likes
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.
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?
2 Likes
We don’t have a significant problem apathetic voters yet. If the nuteam is not already being paid now, I don’t see urgency to mobilize them to implement frequency voting.
Technically the motion doesn’t specify when this should be implemented so the above is not a reason not to vote for it.
About the cost, how do we estimate cost of nuteam’s work?
That would break many things. But you’re right, implementing the random part is pretty easy (and Bitcoin code already provides functions to get random numbers), but it’s a tiny part of the modification. Among the things that would need to be done I see that (but I haven’t read the whole discussion so I may have missed some details):
- update the GUI to add the new column
- parse GUI input and handle invalid ones
- merge this pull request to get a different structure for user votes and blockchain votes (because right now they’re the same structure so we can’t store the extra frequency information without adding it to the blockchain too): https://bitbucket.org/JordanLeePeershares/nubit/pull-requests/247/fix-vote-serialization-problem/diff
- update the user vote structure to store this new information among each motion vote
- update the code that generates a blockchain vote from a user vote to take the frequency into account
- update the vote JSON parsing (used by the setvote RPC and when a vote is received from a data feed) to parse the frequency parameter (and probably still support the old format which would put 100% as frequency)
- update the code that dumps a user vote to JSON to add the frequency (and actually we would need 2 versions of this dump because dumping a user vote will become different than dumping a blockchain vote)
- write some automated tests (they would be written first actually)
- update the client version
- build and test one or more RC releases
- build the final version
6 Likes
Thanks @sigmike for providing us some specifics on what is involved. That helps with coming up with a proper estimate for the work. As @masterOfDisaster asked above, would you also be able to elaborate on why you and Jordan decided against something similar? Do you recall what the reasons were?
Forking is rather costly and I don’t think somebody would be really that committed to it, but is doable. An application for not-so-apathetic voters is that some only care about a subset of all motions and would rather vote neutral for others.
Another way would be to publish datafeeds to mimic this behavior. Yet another dirty hack would be to do all this through RPC, if only to build a prototype. Cost-benefit aside, because the goal is to reduce the influence of apathetic voters and reduce centralization, there can be steps taken before we reach the final product.
I think Jordan is talking about 2 different things:
We talked about using the votes in the blockchain as data feed. That was rejected mostly because of privacy issues for the data feed providers and the lag it introduces.
We also talked about making the user votes fuzzy to protect privacy of shareholders (to prevent linking different NSR addresses that vote identically). Your vote would be slightly randomized before it’s put in the block you create. The mean value would be what you voted for, and the variance would be a parameter you choose. I don’t remember we rejected that, but instead I remember we decided it was not a priority.
It seems that this draft is causing some controversy. I would have to read it carefully to get a proper understanding of the problem and the solution proposed before expressing my opinion on it, I feel.
Thanks @sigmike. I like a lot your writing style. No emotions, just arguments.
I would like to hear your opinion about Frequency Voting when/if you have time.
I really feel very bad about this, and I wish that if shareholders ever feel ignored they should protest as loud as they can.
I ask everybody that feels it, one way or another, to be more specific and point out what has be ignored by whom.
In most discussions happening on this forum I personally consider myself a shareholder, not someone who is called to act. So if I am not reading / participating in some discussion, I am acting as a “bad” shareholder, not as a bad team member.
My focus and space is liquidity and NuBot, and when I don’t participate in those discussion, I am being a bad developer. Please tag my username if you wish I participate to somewhere specific.
This community is so full of talent that sometimes I feel safe not reading something and confident it is in good hands.
So please, when you criticise make sure you direct your concerns in the right direction : was he/she being a lazy shareholder or a non-responsive developer?
Now, if you count team members whose action directly impact the course of the technicalities of the network, then you’ll have a lot of burden on just a few people.
Personally I wouldn’t tinker with it much because in open source project I rarely have seen these high level of productivity from core developers, especially, as @Chronos once joked , with such “low rate of LOCs/chats” .
To sum it up : raise your concerns as soon as you have one and try to be as specific as possible, and remember to discern dev/shareholders role of each person.
my 2 cents
3 Likes
I read the whole discussion, I couldn’t resist.
Brilliant. And convoluted at times. But definitely I am glad I spent time catching up with it, and sorry I haven’t replied earlier. I have so many comments after 68 posts that I’ll try to keep it to the essentials, and use a separator to change topic.
Please take my comments as someone completely unfamiliar with the matter who is trying to decipher it. Help me and try to be patient if I didn’t grasped something correctly.
First I want to understand the “why” of this system. By reading the discussion I can extrapolate this as your main source of reasoning (please correct me if I am wrong) :
we would be totally frozen out with a 50% apathy rate.
while with frequency voting
we could still function at 0.01% voting
but then as I keep reading I find something that puzzles my mind a bit.
in @Nagalim’s own words
To pass, a motion would still require very close to 50% support. […]
With 30% support, however, a motion really doesn’t have any chance of passing with or without frequency voting.
I think it’s just a matter of wording, right?
So what is the “50% support” in your above sentence? 50% support among non-apathetic voters?
Let me try to rephrase it in my own words : frequency voting will make a motion tend to pass if more than 50% of active voters vote for it, as opposed as 50% of active minters in the current design.
EDIT : Then how do you distinguish an active voters from a non-active voter? How do you distinguish someone who is apathetic from someone who is willingly not voting for any motion?
Careful with the “it’s not a protocol change => its a light change” argument. The degree of impact of a change isn’t just related to “protocol, non protocol” : I can think tens of examples of protocol changes that have less impact on the network that forcing an automatic behaviour of the client. Actually I would call anything that obey a written rule systematically a protocol. It’s not THE block chain protocol, but it is a part of the stack of protocols of the network.
This discussion is too complicated to understand for many readers and shareholders. If you want to elicit more replies I suggest you make the effort of making an ELI5 and renaming this motion from frequency voting to a Automated Voting, “follow the lead” , or “On apathetic voters” .
@masterOfDisaster described it nicely :
a very nice way to keep the Nu network able to make decisions even if some or many voters don’t care about voting and are fine with following the lead of voters.
Question : is this only for Motions (binary votes), right? (and how it could be adapted to the others vote) .
Because at the current state it just target motion problems. And I evaluate the risk of being stuck with passing a grant waaay bigger that being stuck with passing a motion.
You are introducing basically passive voting by default, if I understand correctly. These passive votes would go towards the most voted motions (in a given window of blocks). Is there any case of this approach in democracy? The closest thing I can think of is the “majority premium” that gives extra seats to the winning party of an election. Wouldn’t this have the same effect of make the majority stronger? Or the average stronger?
Implications are absolutely nontrivial.
I don’t know how to read some of the charts because the legend is too small for me to distinguish what each color represents. I can’t comment on that now
While this looks sound from a technical angle, its a UX disaster.
If this change is aimed towards passive voters, adding an extra field to fill for each vote, will not help. Actually it will have the opposite effect in creating confusion among active voters like myself. When I mint I want to vote for all the motion I entered, I see no point in having a probability field. (ndr: Moreover, why default it to 0? It means that by default when I enter the hash I am not voting for it…Which is a bit counterintuitive, isn’t it? )
I would just add a checkbox somewhere in the “votes” tab called “Follow the lead - Automatic vote” which will disable buttons in the “votes” tabs.
I will try not to comment on the 50 NBT (a bit offensive if taken literally), and will try to read between the lines and understand that @Nagalim simply wanted to emphasise how a small change could have a big impact.
@dysconnect said:
I can definitely vote and rally for frequency voting but I prefer to also add a few (cheap) safeguards.
I’d also will consider adding some safeguard before implementing anything similar. In the draft I didn’t see any, correct?
@dysconnect said :
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 sounds a lot like what I predicted 1 year ago on the bounty proposal thread :
However, with new functionalities added on daily basis, NuNet enables an always growing array of possibilities. It is very hard - if not impossible - for the core-team to explore new territories while focusing on the critical day-to-day activities.
4 Likes