[Withdrawn] Faster motions

Yes. I did.

Will a bigger window size prevent that? No.

The idea of a tiered model is good, but creates new problems like

A tiered motion model doesn’t solve the underlying “problem”: a majority is a majority.
Whether the majority lets the motion pass in 2,000 blocks, 10,000 blocks or 50,000 blocks doesn’t matter.
I’d see that differently if we were talking about extremely short periods. Say a motion were to pass with 11 votes in a rolling window of 20 blocks.
I can clearly see the risk there. Pure luck could make it possible to let a motion pass although only a minority is in favor of it.
But we are talking about 1,001 out of 2,000 here.
And we are still talking about motions and not grants.

This is the first time I’m glad that Nu has no ternary voting system.
Unless a vote is configured in favor of a motion, it’s configured against it. Full stop.
For a motion to pass you need a majority of votes to be cast in favor of the motion.
This is an active process that can be done manually or assisted by registering to a feed.
If you do nothing, you will never help a vote pass. Never.

You don’t need to convince people to vote against anything.
If you want to see a motion pass, you need to convince them of the use of the motion.

This motion here speeds up the voting process.
I can hardly think of a scenario in which this would really be necessary as motions initiate actions which will need to be taken after the motion has passed.
In most cases this action will take longer than the motion needed to pass.

One question is: is it really necessary to save (in best case) 80% of the time the motion needs to pass (1,001 blocks instead of 5,001; not considering that it takes time until there are more than 50% of the blocks carrying votes for the motion)?
I don’t know. Do you? Can you for sure say that there will never be a day at which it a quick passing motion could be missed? How can you prove that?

Another question is: does it hurt to reduce the rolling window size?
This is something that can be mathematically or logically analyzed.
Maybe somebody with more practice in statistical topics wants to chime in to calculate at which minimum window size the variance is sufficiently small to have close to no effect compared to a 10,000 block large window size.
Because this is the main difference.

What seems to disturb many is that with a smaller window size the effects of a majority deciding can be seen sooner than with a bigger window size.
The refusal might be rather related to psychological topics than to security. Seeing a motion pass very quickly, a motion some don’t like, creates a feeling of helplessness.
If the window were bigger you could nourish that feeling a little longer…
…in the end the motion would pass anyway.
>50% is >50%

I don’t want to step onto anyone’s toes with this post. At least not harder than necessary to direct the focus to the gist of the matter :wink:

If something needs to be passed within 24 hours doesn’t that really negate the opportunity for many people to have a discussion on it? The current system enforces at least 3.5 days of debate. We’re a global organization, not only does this change push out smaller holders it could allow for motions to pass before they even get home from work. Even for some people who spend time away from their PC’s on the weekend could have things decided that they may not agree with. I think datafeeds could make the situation even worse if they don’t have the capability to check up on or access their client for a day or two. The potential for future abuse is far greater than the undertaking it would be to implement a more refined solution.

I misread that portion of your example and agree that it holds a more serious consideration than my response provided. It’s still a wildly ridiculous scenario that only exemplifies having these plans in place and discussed now rather than adjusting the motion system. Proactive solutions are well planned out rather than reactive solutions have been continuously abused, which is why I referenced devastating reactive solutions like the patriot act and bank bailouts (hell, lets throw the Iraq war in there too).

If there is a realm of the network that should require quick reactive decision it should be decided upon ahead of time after ample discussion. Reactive decision making has proven to be abused and far less beneficial to those within the sphere of influence, or even outside of it in the case of Nations calling for War.

I didn’t make that assertion and you know that I respect you even if I flat out disagree with you. This is a massive change that removes many many smaller voices from the table with a huge potential for abuse. I’m not dismissing your opinion I just believe the benefits monumentally don’t outweigh the risks, and the ends can be achieved by being more proactive than reworking the system to be more reactive. People are ultimately behind the votes, and they can be emotionally tweaked to make decisions that aren’t in their best interest when put on the spot.

Shareholders already have as much flexibility as possible to share their opinions on the network. Nothing is stopping anyone from advancing any motion they want about anything right now in this moment. Putting forth variable duration’s don’t really satisfy the biggest concerns with the shortest duration. It shouldn’t even be an option. The potential to push out voices and abuse the system is still there.

Only if you could embed the motions (not only the hash, but the motion text) into the block chain or reference it reliably from there.
Peermessage/Peerapps is a system that might be adjusted to do that.
But I see no need for that.
Would it prevent a majority letting a motion pass? No.

Absolutely not.
It enforces a minimum time for a motion to pass (after the first vote has been written into a block) of at least 3.5 days (5,001 blocks).
No debate is enforced. The protocol doesn’t know there was a debate. The protocol doesn’t even care about that, because by protocol nothing happens after a motion passes.
People are allowed to do, prohibited to do, need to do things after motions pass. Nothing more, nothing less.

If the don’t configure to vote for the motion, they vote against it - whether they know of the motion or don’t know.

Like I said:

If the many many smaller voices are dwarfed by a majority that is voting for a motion, they can’t do anything no matter the size of the window (still assuming the window isn’t ridiculously short).

Having a 10k block window instead of a 2k block window absolutely improves the diversity of voters to ward off larger insiders gaming the voting. It’s not intended to prevent votes from going through completely, but instead to prevent decisions from getting hijacked by a fewer set of individuals.

Users abusing the network to vote in a rogue custodian account getting 10 billion NuBits or motion votes should be treated with the same level of concern. While the motion votes have no immediate impact they can have far more impact in the future of the network.

Motion votes indicate the will of shareholders and this change limits the voices involved, and that has potential for abuse, which is why custodian votes will not be changed.

We should continue the same level of concern for motions, not reduce it.

You are aware that you are answering a quote of mine which was my résumé of rogue voting?

This motion as controversial as it’s discussed meanwhile by some individuals still hovers at 35 of last 100 blocks - and it got there quite fast.
The reason why it is at 35 of 100 might have to do with the fact that @JordanLee has posted it.
The same effect could be seen with the NBT burn motion provided by @Nagalim and the one provided by @JordanLee.

Individuals have an effect.
But I don’t consider it hijacking.
Don’t take that for slavish obedience, but I have high regard for @JordanLee’s work as architect. And I hope that he always tries to do the best for Nu as long as he has this role.
Still I was very critical at the beginning. I changed my mind, because from my point of view it makes no difference whether to wait for a majority in 2,000 blocks or in 10,000.
I can’t prove that with numbers, but according to my gut feeling 2,000 blocks is sufficiently large to eradicate variance.

After 7 days the chance of successful minting for an UTXO doesn’t increase. It wouldn’t even help to stop voting to gather more coin age and increase the chance by that, right?

How will you game a motion that passes with 1,001 of 2,000 blocks unless you convince a majority to vote for it?

This is frustratingly pedantic and you know that the point of the statement was that it enforces a duration of time that people have an opportunity to express their concerns or agreements. I’m not sure why you go on to trivialize the point of motions votes and their outcomes but I’m guessing it’s also the attitude that doesn’t see any concern with reduces the diversity of votes in the voting window. I think it’s totally reckless to look at motion votes this way. They should be regarded as important to protect as custodian votes.

I’m sorry. I think I’ve put emotion in some of my statements and picked an inappropriate tone.
It’s not my intention to frustrate anyone.
I’ll take a break and think it over.
Maybe I’m wrong with my assumption about diversity and that it doesn’t change in general between a block window of 10,000 and 2,000 that is required for finding a majority.
You have my apologies.

1 Like

I think it’s been a very strong discussion. I apologize if my arguments seemed personal as they were not intended to be so.I think I’ve shared (and reshared) my concerns on the matter, and it’s time for me to bow out from the discussion as well.

2 Likes

Good discussion here. I need some time to digest this. My use case question haven’t been answered satisfactorily and my gut feel says it is not a good idea, but I’m not sure if I’m able to explain why other than what have been said above. I like the layered model Tom proposes but I’m afraid that the complexity is too high indeed at least at this stage.

I won’t be adding this motion to my data feed in the next few days which might become indefinitely if no new perspectives are presented.

2 Likes

I have to admit to still being very much on the fence on this issue.
I like the idea of being able to quickly pass a motion but my caveat would be that there has been suitable visability and discussion around it. There have been motions in the past which have gained a majority consensus through discussion but which still take an extra few days to pass.
That isn’t what this shortening of the voting period does though, as has been pointed out, this could lead to motions which could pass without that discussion.
I like the flexability shorter voting time gives but I don’t like the possability that it could be more open to abuse.
I think that, like @Cybnate, I’ll have to digest this further.

3 Likes

@assistant motion vote 04512be5c164e77dd354a8267d59f2f11fba29c2

Hi @willy

Here are the details for the Motion Vote on 04512be5c164e77dd354a8267d59f2f11fba29c2:


##04512be5c164e77dd354a8267d59f2f11fba29c2
Blocks: 2332 (23.320000%)
Share Days: 2131811962 (42.022881%)


@assistant motion vote 04512be5c164e77dd354a8267d59f2f11fba29c2

Hi @cryptog

Here are the details for the Motion Vote on 04512be5c164e77dd354a8267d59f2f11fba29c2:


##04512be5c164e77dd354a8267d59f2f11fba29c2
Blocks: 2371 (23.710000%)
Share Days: 1721210943 (38.787730%)


The motion to make auction size adjustable took 10 days to pass.
It passed just after that the deadline that set the size of the next NSR auction .
This lag showed that we need faster motions.
What about starting with 2001 blocks (2~4 days) instead of the originally proposed 1001 blocks (1~2 days) ?
I would vote immediately for such a modified motion.

Both decisions were based on motions.
If motions had been altered to pass with fewer votes, both motions would have been affected from it.
So this is no reason for faster motions.

But as long as Nu doesn’t have automatic ways to burn NBT (and need to rely on manual interaction like the NSR sale / NBT burn motion) it might be good to be more agile.
Still the motion would move much slower than the market and it wouldn’t have a feedback loop on protocol level.

So this wouldn’t be a fix, but a workaround until Nu will be equipped with an automatic, continuous and reliable way to do that (which Nu desperately needs!).
I very much like this draft:

2 Likes

It may have made the time between when the auction motion passed and the auction control motion passed be less than a week. They both would have gone out faster, but the time between them also would have shrunk.

That said, I think this situation was hyper specific and rare. I think we should continue to discuss this motion (and possible variants if we don’t think this motion has been getting support) but we should not be quick to make the current situation indicative of future events. We have a full history of motions to look upon.

1 Like

The motion to make auction size adjustable also took longer because it didn’t have a majority of voters at times. Faster motions won’t really help with that anyway. Still not convinced that faster motions is the answer.
For the burning we just have the manual burning in place, also Jamie burnt a lot in the last day. So it is hard evaluate what the effect is. Automatic ways can be better, but it won’t hurt to keep a human factor in it to start with. But I’m digressing from the topic.

@assistant motion vote 04512be5c164e77dd354a8267d59f2f11fba29c2

Hi @cryptog

Here are the details for the Motion Vote on 04512be5c164e77dd354a8267d59f2f11fba29c2:


##04512be5c164e77dd354a8267d59f2f11fba29c2
Blocks: 1546 (15.460000%)
Share Days: 853507570 (22.375634%)