Is the probability to find a valid hash higher if the UTXO is 50,000 NSR instead of 10,000 NSR?
Yes, 5 times higher
Referring to the example of a rolling windows of 2,000 blocks that means, one can tune the UTXO to be split into lots of 50,000 NSR to five-fold the chance to successfully mint blocks (compared to those who mint with UTXOs of 10,000 NSR, which is the optimum for maximizing the average ratio of minted blocks).
This adjustment of increasing the UTXO size decreases the amount of NSR that can be gathered as rewards over time (because it’s a static per block reward).
But with that approach one can (without increasing the total amount of NSR!) increase the chance to successfully game the reduced rolling window by waiting until all (sized 50,000 NSR) UTXOs have gathered enough days to mint before starting to vote for a motion.
While reducing the average ratio of minted blocks, the probability of minting in a given rolling window can be maximized by increasing the UTXO size.
The ideal amount of NSR per UTXO depends on the total amount of NSR and the size of the rolling window. If the UTXO size is too big, there might be not enough UTXOs to get >50% of the blocks in the rolling window.
I’m currently not able to express this mathematically, but I’ll think about a notation.
I hope that even without providing a formula, it’s become clear what I’m talking about.
We had a lot of discussion a while ago about removing sharedays from the voting: Using share days destroyed as vote weight However a motion was never progressed as far as I know.
I’m fine with removing the sharedays, but I’m on the fence with reducing the number of block to pass a vote at the same time. I share the security concerns. We need some more discussion about possible attack vectors to manipulate the vote like MoD did above.
Maybe we need to keep the Sharedays to ensure security with a shorter blockcount?
This motion is on hold for me till the implications are more clear
The attack that I sketched above is not rendered less likely if share days are counted as the base idea for that attack is gathering a large amount of share days (by increasing the UTXO sizes) to increase minting probability.
Yes, someone can give up some average reward to get some increased chances to mint during a specific window.
There was a motion and it passed: [Passed] Motion proposal to give all votes the same weight
Note that this is already the case with 10k block motions, maybe to a lower extent but I’m not sure.
It is true that an output of 50,000 is five times more likely to find a block in given time period than an output with 10,000. However, 5 outputs of 10,000 will have an equal chance of finding a block as one output of 50,000. Additionally, only the 5 separate outputs will have any chance of finding two or three blocks within a single voting period.
Larger transaction outputs degrade the ability to find many blocks within a certain time frame. This is because the entire output becomes ineligible to mint for 7 days.
The best way to find as many blocks as possible is to split NSR into outputs of 10,000 (clients do this by default) and begin minting after at least seven days with no minting. This will temporarily increase minting power about 20% versus constantly minting, because no outputs will be in the 7 day waiting period.
Remember what happens when a motion is passed: absolutely nothing (in the software or protocol). It is just a signal to humans to begin to take the agreed actions. So if the outcome of a motion is contested, it can be contested after passage. Like the open source motion was.
I believe making the network incapable of taking novel actions for approximately a week is a significantly greater security risk than lowering the number of blocks in the voting period for motions.
1 Like
I did a simple calculation to compare one output of 50,000 with five outputs of 10,000.
I agree that due to the very low chance of finding a block of both an output of 50,000 as well as an output of 10,000 the chance to find (at least) one block is practically equal.
I don’t have the numbers to make a precise calculation, but assuming that roughly 600,000,000 NSR mint, there are give or take 60,000 outputs of 10,000 NSR or 12,000 outputs of 50,000 NSR.
Assuming further that the chance to successfully mint of is equally distributed between the outputs (which is not necessarily true), the chance for the outputs of 10,000 is 1/60,000 or roughly 1.610⁻⁵ while the chance for an output of 50,000 is roughly 810⁻⁵.
Calculating complementary events to determine the chance for finding at least one block, the result for the outputs of 10,000 and 50,000 is more or less the same.
The chance not to mint a single block with 5 times 10,000 NSR is (1 - (1.6 * 10⁻⁵))⁵ = 0.99992
The chance not to mint a single block with 1 times 50,000 NSR is 1 - 8 * 10⁻⁵ = 0.99992
The chance to mint at least one block with either 5 times 10,000 NSR or 1 times 50,000 is the same: 8*10⁻⁵ or 0.00008
Admittedly you can only mint one block with a single output of 50,000 NSR.
But for comparing the two output sizes the question needed to be “what’s the chance to mint at least one block”.
That renders the attack scenario (I had sketched) unfeasible in my eyes.
Taking into regard that this reduced rolling window size gets only reduced for motions and not for grants, I’m in favor of this motion.
Based on @JordanLee’s last post and my calculation I come to the conclusion:
The agility with that motions can pass is not aligned with security drawbacks unless somebody else can think of feasible ways to game the reduced window size.
The benefit doesn’t need to get paid for with drawbacks.
It might look different, if the rate of minting NSR were comparably low.
But I don’t see a low minting rate coming as only minting secures the block chain and provides the means of voting which I assume to be the main reasons why NSR holders mint.
1 Like
I feel we need a rapid way to respond to situations.
What has been the average required time to pass a motion so far and what would be the estimated new time if this motion passes?
It is around a week, it will be like a day or two, as far as I understand.
Ok tks!
maybe an idea, to support different periods, for high priority motions, and motions that need more discussion, this could end up though, that everybody will just use the high priority type. So, don’t know if my suggestion is a good idea. Two days seem rather short tho.
I tend to agree. But on the other hand when a motion can gain a majority in such small time-frame than it must be a no-brainer. I doubt many motions would qualify though. So what would be the use cases in order to spend time on this?
1 Like
I can’t think of a use case at the moment that requires or profits from a rolling window size.
But like explained it is not less secure either to reduce it.
In the end I’m in favor of this motion, because it offers a conceptual benefit:
motions are faster with it - there’s more motion in them 
Between starting them and gathering enough votes to pass less time goes by.
That can be an enormous advantage in case something is needed urgently that can be addressed by a motion, although I can’t think of a particular motion right now!
Right! The motion can only pass if a majority of votes are for it. The motion doesn’t pass just because somebody put it here on the forum or somewhere else.
So this doesn’t stop or limit discussions.
1 Like
i see, two days is only when the majority agrees that quickly, i guess it is fine like this
1 Like
Is there a reason that this proposal is needed now? Did we find ourselves in a situation where it would have been beneficial to have a motion past faster than the 10,000 blocks that is currently required? I’m not sure I’ve seen anything contentious that would have triggered the need for such a radical change.
I disagree with a 48 hour window for motions to potentially pass. It’s common for people to take a day or two to step away from their computers (long weekend trip, for instance). While I’ve been an advocate of figuring out ways to seek consensus quicker, the duration just feels too short to me. 72 hours (~3000 blocks) instead?
2 Likes
This isn’t accurate. If the community has only 48 hours to put together a discussion that could sway some members of the the majority to go against the proposal the new timeframe certainly could stop or limit discussions.
1 Like
how I understand it now it is a minimum, 1001 votes in any 2000 block period. Consensus can be made quicker, and only for motion votes (not custodial), the 1001 votes can be reached in any 2000 block period, most motions will still probably take longer than 48 hours, I guess.
If we change our perspective such that you have to be swayed to vote rather than swayed not to vote (which is the way the protocol is set up anyway) then this isn’t an issue. Though I agree, this motion puts a bigger burden on shareholders to avoid voting for motions that haven’t had time to be discussed.