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.9077889018
So 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.999996366883
It’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)^w
So the probability for casting at least 1 vote (of v available) in a window sized w is calculated by
1-((85000-v)/85000)^w
The 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”.