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.
Hi @cryptog
Here are the details for the Motion Vote on 04512be5c164e77dd354a8267d59f2f11fba29c2:
##04512be5c164e77dd354a8267d59f2f11fba29c2
Blocks: 1546 (15.460000%)
Share Days: 853507570 (22.375634%)
For reasons I don’t understand I have missed this thread since 25 days ago.
Anyway I share some of the concerns. Here is my idea to check the advantage of a shorter motion window: intruducing a cost.
If it is mandated that all motions passed with 2,000-block windows to be nullified after 7 days of passage, then a normal 10,000-block window motion will have to pass to make the motion permanent, with all due debate and deliberation.
The onus is on the motion proposer to do extra diligence to make a quick win permanent.
2 Likes
very interesting. We could do the tiered motion this way too, with short term motions, medium term, and permanent motions. This would allow us to have a lower threshold for something like a pool’s continuation proposal if no additional funds are required. In theory, nullification windows are only one possibility. We could define a set of clear, undebatable criteria that a motion must satisfy in order to be passed in a shorter time frame.
Where exactly shall the the danger from a reduced rolling windows size be coming?
I’m not talking of a rolling window size of 10 blocks here, but of 2,000 blocks like proposed.
While I agree that in general bigger windows sizes aren’t less secure than smaller sizes, they are not necessarily always more secure.
Basically this is what this security discussion is about - how far can we go below 10,000 blocks window size before the security is degraded by x %.
And what is “security” in this case?
One aspect of security is dealing with the variance when minting - if variance plays a big role for the outcome of a voting, I consider this relevant for security.
I still believe there’s not necessarily a big difference between 10,000 blocks and 2,000 blocks.
So far this hasn’t been calculated and I need to rely on my gut feeling.
A tiered motion model would help feeling better, but as long as it’s not sure that a 2,000 block window is (much) less secure, it would only introduce unnecessary complexity.
Can we try to focus on a mathematical comparison between the security of a 10,000 and a 2,000 block window size?
How is the voting probability depending on window size (and number of votes someone has)?
It would be amazing to calculate the “security” of any window size.
I think the start for this could be to calculate the probability of a single vote being in a given window size.
I need to make some assumptions/roundings. I hope they don’t ruin the outcome.
850,000,000 NSR are distributed.
Lots of at least 10,000 NSR can cast a vote.
85,000 votes are available in total (some need to wait until they have enough age).
I don’t know how to calculate the currently minting NSR, but let’s introduce a factor of n.
Let’s call the window size w.
Say someone has a total number of available votes v.
So n*85,000 votes are competing to put votes in w blocks.
I want to leave n out for now and set it to 1, meaning all distributed NSR are minting (which is not the case).
And now comes the point, where I need to make roundings. Once one of the 85,000 votes is cast, it will neither be able to cast in a 2,000 nor in a 10,000 window size.
It’s beyond my skill level and the capabilities of discourse to express that in a formula.
Each vote has the same probability of casting a vote which is not exactly true.
If you have v total votes, you should be allowed to expect at average each v/85000th vote.
For both 10,000 blocks and 2,000 blocks you can’t cast the same vote twice (7 days (10,080 blocks?) output age required to vote).
The probability to put (at least) m votes in a w sized window is the sum of the probability of the complementary element of not putting each of the votes there.
For 2,000 block the accurate calculation is
1-(84900/85000
*84899/84999
*84898/84998
*84897/84997
*84896/84996
[...]
*82901/83001)
=
1-(0.9988235294
*0.9988235156
*0.9988235017
*0.9988234879
*0.998823474
[...]
*0.9987951807)
=1-0.0922110982
=0.9077889018So with a probability of a bit over 90% at least one in 2,000 votes gets cast if you have 100 votes available.
With a windows size w=10000, a total number of available votes v=100 the accurate calculation is
1-(84900/85000
*84899/84999
*84898/84998
*84897/84997
*84896/84996
[...]
*74901/75001)
=
1-(0.9988235294
*0.9988235156
*0.9988235017
*0.9988234879
*0.998823474
[...]
*0.9986666667)
=1-0.00000363311666069707
=0.999996366883It’s not easy to calculate this for different window sizes w and different numbers of votes v.
That’s why I thought of an approximation.
The probability for casting 0 votes in w blocks is calculated by (I hope the brackets enhance the readability)
((85000-v)/85000)^wSo the probability for casting at least 1 vote (of v available) in a window sized w is calculated by
1-((85000-v)/85000)^wThe above is not accurate, because after each vote the number of available votes is reduced by one.
It’s dealing with casting only one vote, and only close to the precise value for small numbers of v.
But except for that it’s a quite good approximation 
Allow me to compare the order of magnitude of the approximation and of the precise calculation for v=100, w=10000
The approximation is 1-(84900/85000)^10000
=0.999992279502
The precise value is
=0.999996366883
As you can see it’s close to each other.
Let’s resume:
there’s a 99.99 percent chance to put at least one of 100 available votes in a rolling window of 10,000 blocks.
And there’s a 90 percent chance to put at least one of 100 available votes in a rolling window of 2,000 blocks.
This might look like a big difference.
But if you do some calculations with other numbers of available votes, you’ll find out that the number of available votes has a bigger impact than the size of the rolling window.
If you increase the number of votes to v=200 the outcome is as follows:
Probability to cast at least one vote in w=10000 blocks:
1-(84800/85000)^10000=0.999999999941 (the precise value would be 0.999999999987006)
Probability to cast at least one vote in w=2000 blocks:
1-(84800/85000)^2000=0.991008066532 (the precise value would be 0.991521253204478)
As you can see there’s almost no difference between the 10,000 and the 2,000 window size for owners of 200 votes.
This gets much more complicated if you want to calculate the probability of m votes and I can’t think of a proper approximation.
But calculating the probability of 1 successful vote in different window sizes of w gives a hint about the differences.
Owners of small numbers of votes are more affected from a change of the window size than owners of big numbers of votes.
This is especially true if you do calculations for more than 1 vote.
Someone with 2 votes has only 1 left after the first one was successfully cast (50% of votes left) while someone with 100 votes still has 99 (99%) left.
I don’t know how many NSR owners use data feeds. But the data feeds mitigate these effects to some degree.
Sorry for the text wall.
But I wanted to contribute something “measurable”.
2 Likes
This is beautiful, and reaffirms my intuitive feeling that this motion is bad for people with few votes but now we know precisely why and by how much. Thank you @masterOfDisaster
1 Like
For the record some more numbers.
With v=10 (equals owning 100,000 NSR) the probability to cast at least one vote for
w=2000 is roughly 21% and for
w=10000 i’s roughly 70%.
with v=20 and
w=2000: 37%
w=10000: 90%
with v=40 and
w=2000: 61%
w=10000: 99.1%
with v=80 and
w=2000: 85%
w=10000: 99.99%
with v=160 and
w=2000: 97.7%
w=10000: 99.99%
with v=320 and
w=2000: 99.94%
w=10000: 99.99%
with v=640 and
w=2000: 99.99%
w=10000: 99.99%
Owners of several million NSR don’t need to care much about a reduced window size.
Owners of less than some million NSR might face variance issues.
Please take into regard that there are some assumptions and roundings in my calculations.
Plus Nu is closer to 60,000 competing votes than 85,000.
This reduces the impact for people with few votes.
But the effect from votes that are cast which need to be excluded when calculating the probability of the next successful cast of a vote outweighs that by far.
This is once again a gut feeling, but I’m too lazy to calculate that.
1 Like
Thanks @masterOfDisaster for these elaborations.
Now, what’s a sufficiently distributed Nu?
- how many shareholders?
- how many shares each?
- what’s a good w then?
http://blockexplorer.nu/topNSRaddresses/1
Sorry, I was in a rush, the y-axis is actually Log(v), which is Log(NSR)-4.
The fit for the linear part (given the log scale) is:
y = -0.0041x +3.1013
The reasonable thing, in my mind, would be to find the median address and pass motions for it. The x-intercept is 756, so the median is #378, at v~35, or 350,000 NSR.
Next, we choose an allowable % and that gives us our w. Something like 90% might be a good choice. Plugging in with @masterOfDisaster’s formula, and I get a w~5600
2 Likes
Motion RIPEMD160 hash: 4a083131a9260114f1b14793449691965d6b4cfb
=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=
Currently a motion must receive 5001 votes within 10000 blocks and also have the majority of share days voting in favor of it in the same 10000 blocks.
Passage of this motion will change what is required for all future motions to be regarded as passed in these two ways:
- Share days will no longer be a criteria for evaluating the passage of a motion. One block equals one vote.
- A motion passes with 2501 votes in any 5000 block period. This will permit decisions to be made more quickly, while still permitting a diverse set of shareholders to participate.
Custodial grants will continue to require 5001 out of 10000 votes because the security concerns for grants are much higher because they automatically issue blockchain funds, whereas no action is automated in the case of a passed motion.
The getmotion RPC should have the default block height changed from 10000 to 5000. Blockexplorer.nu needs to be changed as well. However, these changes need not be made in order for the new rules to take effect.
=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=
Verify. Use everything between and including the <motionhash></motionhash> tags.
1 Like
I think you are not precise. At now custodial grants require 5001 out of 10000 votes. Do you propose to change that?
I don’t think that is the point. Indeed for the same static set of yes and no voters you get the same result no matter how long the window is. However 2000 blocks window brings more risk because it gives less time for voter to seriously consider. The key is that shorter windows cause more variance in the results when the underlying opinion set is not static and needs time to settle.
If voters have less time to consider, what happens?
Do they vote for such a motion, although they are not done with considering?
Or is it more likely that they keep voting against the motion until they’re done with considering?
What happens except for the motion success being postponed (in case a majority can be found)?
In that case Nu might not be able to profit from a reduced rolling window size.
In cases where voting for a motion is a no-brainer, it can speed up the time between starting and completing a motion.
Where is that risk coming from?
Or they think they are done with considering given the one-sided seems-convincing arguement presented in the motion, in a short window, although a longer window could allow them to think more and people with a different view to have a chance to know about the motion and speak up.
I’m proposing 2501 out of 5000; the original motion (with only %7 support after 26 days) was proposing 1001 out of 2000.
I know you’re saying that there is a certain amount of time for a community to achieve consensus, and I hear you, but I do think it is the responsibility of the voters to not vote for something until they are convinced they’ve heard both sides of the argument. If we assume that is the case, then I really do think this comes down to a question of wealth distribution and allowing the median voter to have a say. That is why I proposed 2501 out of 5000, because it is shorter, but still long enough to give the median voter a say.
My question is about custodial grants, not motions. Your proposal modifies rules not just for motions, but for custodial grants too.
You’re very right. That’s a mistake on my part. Shame, I already got a few votes.
I updated the hash, please do not vote for the hash beginning in ‘ae3’. I’ll put up the auto-verify tag when assistant bot responds to me.
The new hash is:
4a083131a9260114f1b14793449691965d6b4cfb
Human nature being what it is, it’s the responsibility of the policy makers to take voters’ actual habit/behavioral pattern into consideration.
The 5000-block window assumes diligence on the voters’ side. It doesn’t solve the need of fast response in urgent situations.
I think setting an auto-expire date to all motions passed with 2000-block window as suggested above is a better choice.
How about:
Motions
2,000 for 7 days
5,000 for 30 days
10,000 permanent
Grants
5,000 for 30 day operations less than 5,000 NBT
10,000 for all else