[Unnecessary] Eliminating SDD for motions

[Nagalim]

–begin–

A Directly Democratic Blockchain

The sole criteria for ratification of a motion into NuLaw is that the cryptographic hash for the motion is recorded in an appropriate manner with 50% frequency in a 10,000 block window. If 5,000 blocks in a continuous 10,000 block span of the Nu blockchain contains the relevant motion, the motion is considered a part of NuLaw.

##Completeness
If two motions contradict and neither specifies how to resolve the conflict, the contract with the lastest 10,000 block span satisfying the 50% criteria will be considered more valid. If both motions are in coincidence or both still being voted above 50%, NuLaw has forked and is unresolved on that particular topic. This does not prevent further Nu operation, allowing Nu to be fundamentally Turing complete.
–end–

[masterOfDisaster]

Good to bring that up again.
Ignoring SDD has been a part of a motion that was withdrawn (mainly dealing with faster motions).
Because the discussion was about the effect of ignoring SDD as well, here for reference:

[Withdrawn] Faster motions

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 bloc…

[Mark]

I think we already voted for this and motion passed:

[Passed] Motion proposal to give all votes the same weight

In the current protocol some votes are weighted by the share days destroyed by the minter. That means a vote cast by an old output will have more weight than a recent output. And a vote cast by an output with a lot of shares will also have more weight than a smaller output. There are 2 problems: Shareholders who (intentionally or not) do not mint for a while will have a bigger impact on the vote when they start minting again. This can cause sudden changes in the result of some votes (notabl…

but release time changed to next protocol update:

Give all votes the same weight

[masterOfDisaster]

Thanks for finding that!
I thought such a motion had passed, but could only find the “faster motions” thread about a motion, which was withdrawn.
I’m getting old…

[Nagalim]

Great! Ok, we’ll do the transition when the rpc response changes. Thank you!

[JordanLee]

As I recall the protocol changes to stop using share days destroyed were the top priority as we closed to the 2.0 development effort, meaning when faced with a decision to delay the entire release or proceed without these changes, we opted to proceed without these changes. I had thought that we would have it done before now, but funding was reduced in the interim.

The changes for custodial grants and park rates must be part of a protocol change, so NuBits release 3.0. However, the change for motions doesn’t require a protocol change because a motion passing doesn’t concern the protocol (nothing happens in the code when a motion passes). In fact, it doesn’t even really require a code change. The RPC may return share days destroyed info, but the community can just decide to ignore it. Shareholders have already passed a motion to do just this, with the presumption it would coincide with similar protocol changes to custodial grants and park rates. Given the long amount of time it has taken to code those changes, I am inclined to suggest we agree to immediately stop considering share days destroyed when evaluating whether a motion has passed. If it is apparent there is broad consensus that we should ignore SSD on motions, then let’s do that. If it proves controversial, then let’s wait for the code change.

What does everyone think?

Edit: we could also remove the SSD info from the motion RPC in 2.1.1

[masterOfDisaster]

I think the decision to ignore SDD was already made, consensus was formed.
It hasn’t been included in the code as part of a protocol change, but as (like you explained) motions don’t do anything on protocol level, I say ignore SDD when voting for motions.

[Sentinelrv]

I agree with MoD and Jordan. The decision to ignore it was already made.

[Cybnate]

I say ignore SDD when voting for motions.

As that decision had already been made I’m good with it. Please have the NuBlockexplorer amended though, so it shows that a motion has passed just based on the number of votes. That makes it more official and more clear for outsiders. Such a change can be that hard. Do we need to raise a grant to have this done?