[Withdrawn] Faster motions

[JordanLee]

Motion RIPEMD160 hash: 04512be5c164e77dd354a8267d59f2f11fba29c2

=##=##=##=##=##=## 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 1001 votes in any 2000 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 2000. 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.

[Nagalim]

What are the implications for pos security and block chain bloat?

[masterOfDisaster]

Although share days will not be criteria for evaluating the passage, the share days play a role for the probability of minting a block (until they are capped after 7 days), right?
Wouldn’t that allow an attack in which somebody with much less than 50% of NSR could try to stop minting to gather a maximum of share days for all the UTXO, create stacks of more than 10,000 NSR per UTXO (to have an advantage in terms of share days over those with stacks of 10,000 NSR), create a motion (which is not for the benefit of Nu, but for the benefit of that person) and start voting for the own motion.
It might be costly to gather enough NSR to make this attack feasible.

But before we go into detail about calculating numbers for amount of NSR and chance for success, is this possible at all?

The current rolling window of 10,000 blocks basically allows the same type of attack, but with a by magnitudes smaller chance of success, because it’s harder to keep majority of blocks for several days than it is to keep majority for a fifth of the time.

I like the agility that is provided by the reduced number of blocks that is required to have a motion pass.
But it’s unclear to me what’s the cost of that reduced rolling window size.
…after all the security of Nu is based on economic costs of attacks; reducing the security creates imputed costs for Nu itself.

[Nagalim]

Yah, I’m not voting for this without discussion. It’s a little absurd Jordan just left this here with a hash without any kind of risk analysis.

[sigmike]

the share days play a role for the probability of minting a block (until they are capped after 7 days), right?

No they don’t because the min age is also 7 days.

[masterOfDisaster]

Is the probability to find a valid hash higher if the UTXO is 50,000 NSR instead of 10,000 NSR?

[sigmike]

Yes, 5 times higher

[masterOfDisaster]

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.

[Cybnate]

Share days will no longer be a criteria for evaluating the passage of a motion. One block equals one vote.

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

[masterOfDisaster]

Maybe we need to keep the Sharedays to ensure security with a shorter blockcount?

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.

[sigmike]

with that approach one can […] 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

Yes, someone can give up some average reward to get some increased chances to mint during a specific window.

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.

There was a motion and it passed: [Passed] Motion proposal to give all votes the same weight

[sigmike]

someone can give up some average reward to get some increased chances to mint during a specific window

Note that this is already the case with 10k block motions, maybe to a lower extent but I’m not sure.

[JordanLee]

with that approach one can […] 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

Yes, someone can give up some average reward to get some increased chances to mint during a specific window.

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.

[masterOfDisaster]

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.

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.

[cryptog]

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.

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?

[Nagalim]

It is around a week, it will be like a day or two, as far as I understand.

[cryptog]

Ok tks!

[irritant]

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.

[Cybnate]

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?

[masterOfDisaster]

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!

when a motion can gain a majority in such small time-frame than it must be a no-brainer.

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.