[Passed] Reduce the total displayed supply of NSR by 10,000

NuShares Motions
#43
#44

That would solve their problem but what about the other users that do use these configs? When should they update them?
The reserve balance and the splitshareoutput are converted to satoshis when they are used so if we just update the COIN value at a specific time the converted amounts will not match the userā€™s config anymore.

A solution could be to always use the new COIN value to convert these config to satoshi (i.e. not wait for the switch time). So users would have to update their config when they upgrade and nothing would change about them at switch time.

The NSR custodian and fee votes. Internally the votes values are stored in satoshis so itā€™s not a problem, but the data feeds provide amounts in NSR. So the data feeds would have to update at the exact same time too. If the data feed providers use the votenotify config then we may trigger it at switch time to make sure they update.

But even so, if the clocks of the data feed provider and the node using it are not in sync, the amounts could be interpreted incorrectly.

But I guess data feed providers could just stop voting for NSR grants and fee a few hours before the switch.

Thereā€™s also the share day calculation. These amounts are expressed and stored as shares*days so the value would change. The easiest solution would be to continue to use the old COIN value for that, because I think nobody really cares about the absolute value as itā€™s mostly used relatively to other share days.

#45

Concur.

You know the internals best, but UX wise, how about deciding a time (block point?) for the Ć·10k change and put a notice in the client about when it will occur plus something until the user has confirmed it understands what happened? Option #1 seems preferable to me from the viewpoint of users. They might upgrade to Nu 2.1 and later be unaware of the change revealed with Nu 2.2. Does that matter thoughā€¦ Either way it seems more people can be made aware by putting something in Nu 2.1.

#46

@assistant motion vote e0b3f80e5d9f58d3c3df27e346b61233b9cd5153

#47

maybe a small drawback, when you have less shares, and the price goes up, you gain less times the increase, of course the increase will be 1000 less probably, so i guess a non issue, just psychological

#48

But the price will go up 10000 times more. Psychologically, Iā€™d rather see 1 NSR go from $20 to $21 than 10,000 NSR go from $0.002 to $0.0021

2 Likes
#49

I donā€™t see how thereā€™d be any difference in such metrics. Can you play with some numbers to demonstrate?

#50

Hi @tomjoad

Here are the details for the Motion Vote on e0b3f80e5d9f58d3c3df27e346b61233b9cd5153:

##e0b3f80e5d9f58d3c3df27e346b61233b9cd5153
Blocks: 4636 (46.360000%)
Share Days: 1674828011 (50.713730%)

#51

Is the blockchain explorer not working properly?
http://blockexplorer.nu/motions

#52

Hi @tomjoad

Here are the details for the Motion Vote on e0b3f80e5d9f58d3c3df27e346b61233b9cd5153:

##e0b3f80e5d9f58d3c3df27e346b61233b9cd5153
Blocks: 4643 (46.430000%)
Share Days: 1677662868 (50.788705%)

#53

Itā€™s been frozen for about a day. Our block explorer guy is aware of it so it should hopefully be fixed soon.

It looks like this motion may pass if current voting trends continue.

#56

I had indicated this change will be a little messy, meaning there are some temporary problems that will be created at the time of the switch. They donā€™t have neat automated solutions, but they will be limited in scope and duration. The problems you mentioned are valid reasons for shareholders to be concerned about this proposal. Opposing the change on the basis of the problems identified is reasonable. I think the change brings us a net gain, but not by a lot. The change is permanent, but the problems will be transitory.

At the time of the switch.

@Cybnate and @cryptog can you confirm you understand this issue and be careful to remedy it at the switch time?

#59

@assistant motion vote e0b3f80e5d9f58d3c3df27e346b61233b9cd5153

#60

Hi @tomjoad

Here are the details for the Motion Vote on e0b3f80e5d9f58d3c3df27e346b61233b9cd5153:

##e0b3f80e5d9f58d3c3df27e346b61233b9cd5153
Blocks: 5004 (50.040000%)
Share Days: 1810040176 (54.118211%)

Current Proof of Stake Difficulty
#61

The motion has passed! I will wait for further comment from @JordanLee, @sigmike and others on what technical direction they would like to take before drafting up our 60-day implementation plan.

This denomination change should help us market our network much easier and I am happy that shareholders agreed.

3 Likes
#62
#63

These values are not very important, but I think having to change the config at upgrade time is better than having to restart the client at a precise time.

I think weā€™re mostly waiting for exchange comments.

Still, about #1:

Exchanges are intensive users of the client and the most likely to find bugs in the large internal changes. So recommending them to make this important upgrade at a specific time without a possible way back adds the risk of a temporary delisting if something goes wrong, until the problem is fixed.

I think itā€™s less risky to have 2 distinct upgrades. Note that 2.2 could also have an automatic switch time if we want. Itā€™s just mixing the important internal changes and the time constrained upgrade that concerns me.

#64

I will certainly comply with above. So count me in.

#65

Issue with the official block explorer. It mentions:
e0b3f80e5d9f58d3c3df27e346b61233b9cd5153 50 votes just now 535,044 3,340 (33.40%) 1,162,269,035/3,145,721,565 (36.95%)

#66
1 Like