Here is a list. The changes being voted on in this thread may also be included if it passes quickly enough.
Though they are not exactly features, most of the resources going in to 2.1 are to improve start up speed and reduce memory utilisation.
The voting rate has consistently been between 25 and 30 blocks per 100 over the past twelve hours. If you are in favor of this motion please add it to your voting as soon as possible so that it can be added to Nu v2.1.
Edit: @Cybnate and @Cryptog given your comments above, do you plan on adding this motion to your data feeds?
1 Like
How do we deal with the problem @mhps refers to? If an exchange fails to comply within the 60 days and users begin depositing and withdrawing absurd amounts, how do we respond? Cold shoulder?
Exchanges will be provided with ample warning across many channels from multiple shareholders. If they choose not to comply that is a failure of their own operations. This motion will definitely require a dedicated communications effort from us similar to what we did with our recent protocol change, but thereās no reason to think exchanges will ignore our requests.
Jordan Lee pointed out that NuShareholders are able to compensate exchanges for any deposit/withdrawal losses, but it wonāt be mandatory. We certainly shouldnāt make any promises to do so. Otherwise, exchanges might conveniently āloseā NSR and demand payment from us.
What are your thoughts?
1 Like
I donāt think we should compensate exchanges. I think if we pass this we need to be super on the ball about making sure every exchange complies and bombarding them with support requests and emails if they donāt. Iām for this, but Iām super duper wary about insuring exchange issues, not for precedentās sake, just because I really donāt want to see this turn into an NSR dilution. I guess we cross that bridge when we come to it.
2 Likes
I think we should not include that in Nu 2.1 because this version will make large internal changes and Iād rather not mix that with an upgrade that must be done at a specific time (at least exchanges would have that obligation).
If thereās something wrong with the internal changes users should be able to downgrade until the problem is fixed. (Even if downgrading will require restoring a backup of the blockchain or redownloading)
So Iād rather change the denomination either before or after the changes planned in 2.1.
1 Like
Your reasoning makes a lot of sense!
I donāt know how others see that, but I perceive the performance issues of the Nu software a more urgent problem than changing the denomination.
Iād prefer having a Nu version that fixes the performance issues first and changing the denomination later.
Exchanges that upgrade to the new Nu client to profit from better performance can be informed about the denomination change in the update info / announcement of the new client.
The performance upgrade is an extra chance to make exchanges aware of the denomination change.
1 Like
e0b3f80e5d9f58d3c3df27e346b61233b9cd5153 verified and voted.
Was about to do that till Sigmikeās post which reduces the priority of this over the 2.1 release.
Given Sigmikeās feedback, I think we need a 2.2 version which is probably not planned for. Keen to understand what that means as it would increase the costs of the execution of this motion.
Edit: will vote for it in case an interim 2.05 is planned for 
How will the motion be interpreted in terms of scheduling? At discretion of current Nu developers or do we need a follow-up motion to specify when to implement it?
1 Like
The schedule is not written in the body of the motion, but it is in the original OP. Itās a 60 day countdown starting from the day of passage.
Iām not satisfied with that answer. Why would the suggested schedule apply when itās not in the motion people are voting for?
Now with sigmike saying it may not be a great idea to implement the motion in combination with the other changes in Nu 2.1, this difference in interpretation seems all the more important to resolve.
3 Likes
The optimizations already planned for 2.1 represent a significant refactoring of the code, which brings with it a considerable risk of unexpected results. Because these arenāt protocol changes, adoption in the production environment does not need to occur at once. It can and should be phased in, starting with just a few people and then progressing to an ever larger percentage of the network. This way, flaws can be detected before the software is widely distributed without having to pay for expensive testing. So, as I understand it, sigmike is rightly concerned about a sudden and complete deployment. That would be an unnecessary risk.
I hadnāt articulated exactly how I envisioned this change being rolled out to anyone, including sigmike, so now is a good time to present that for discussion in an effort to produce a plan that everyone feels comfortable with.
Even though it is not a protocol change, I propose that we include a switch date just like we have in the past for protocol changes. The switch date should be at least 60 days from the time we approve the release for general (as opposed to beta) use. Protocol voting will not be relevant to the switch date.
So, even though I would like to just have one release (it is valuable to avoid having to bother users with 2 upgrades), the changes that were part of the 2.1 plan before this motion was advanced (mainly consisting of complex performance enhancements) will be effective immediately and any problems with those changes can be detected by the alpha and beta users. Long after the release is stabilised and proven in every day use, the switch to change the NSR denomination will come. So, even though we will have a single release, it behaves like two releases in many ways because the NSR changes will occur in an isolated second stage that is triggered by the passing of a switch date.
@sigmike, does this plan effectively address your concern about carefully phasing in adoption of the optimisation changes as well as comply with your preference to facilitate downgrading if problems result from the optimisations?
1 Like
Please take a look at my post just above for details about my proposed deployment schedule. It does not comply with @tomjoadās suggestion in the original post. However, it does comply with the actual content of the motion.
I suggest we leave the motion content unchanged so that voting does not need to start over and deploy as I proposed in the post above.
2 Likes
Is it a common practice that exchanges use their own wallet system instead of the standard client?
I thought about how the change is made.
Is my understanding correct that this is an interface change:
If the change happens at block N, all clients will divide the balance or transaction amount by 10,000 in the output
of all GUIs, and RPC commands, and multiply the balance or transaction amount by 10,000 in the intput
of all GUIs, config files, and RPC commands.
Another way is a protocol change:
If the change happens at block N, all āpreviousā unspent outputs will have their remaining balances divided by 10,000 in an transaction, all āafterā unspent outputs, including those transacted in block N, will have their remaining balances unchanged in a transaction.
Both methods have advantages and disadvantages. The first one is safer but messier. Both methods requires all prices, marketcap, tx volume records on the web to be annotated or updated.
Anyway the effort is not as trivial as 2000 NBT development cost might indicates.
1 Like
Iām afraid there could be bad side effects. Some config values would have to be changed too (reservebalance, splitshareoutputs, maybe others) and we canāt do that automatically. External software manipulating shares would have to be programmed to also change at the exact same time (with some difficulties to interpret values the few seconds around the switch time). An upgrade where the user is in control of the change seems better.
No doubt this change is a little more messy than we would like, which is why we couldnāt do it if the network were any more distributed than it is today.
You are right that some config values will need to change if they are being used. My guess is exchanges donāt have config file entries you mentioned that would need to be changed. Although we should ask. Regardless of how we form the deployment, such config entries would need to be changed. I think we need input from an exchange operator or two about how we could make deployment easiest for them in order to ensure the best decision.
Iām concerned about confusion in the community from asynchronous upgrades. We might have NSR selling at Poloniex for $18 each while they are $0.0018 at BTER, which would make the coinmarketcap figures meaningless as it would be a blend of the new and old price. It is possible that the best choice is to still have a switch date, but just have it implemented as a social expectation, with the code containing no date at all.
So, I see these two choices available to us:
-
Deploy everything as a single release with the denomination change set to actually occur at a specific moment about 60 days in the future. The recommended course of action for exchanges would be to not upgrade until the switch time. Just prior to that time, they would halt trading on NSR pairs, clear their order books, divide the quantity of NSR in their internal database by 10,000, install the upgrade, test and then reopen NSR pairs for trading.
-
Deploy 2.1 without the NSR denomination change and instead place it in its own 2.2 release. The 2.2 release would have no date trigger for the denomination change. The denomination change would occur at the time of install. The community would create an expectation that the upgrade occur at a specific date and time to try to synchronize it.
Comparing these options, #1 carries a higher risk of exchanges not updating their internal database numbers at the right time. #2 does not eliminate the risk though, as it is possible an exchange will just install version 2.2 without adjusting their internal database values. Option #1 will synchronize the change and eliminate any confusion or problems resulting from some people using the new denomination while other continue with the old.
My guess is exchange operators will have a slight preference for approach #2, but that #1 would not place much additional burden on them, and that they will understand the benefit of synchronizing the change.
There is a modest increase in code complexity for option 1, because everywhere the denomination is used an if block will need to be used to test the time/date. We will also need to find a way to reload/refresh the UI at the time of the switch to ensure the changes are consistently applied to a user that has the client open at the time of the change. These if blocks could be removed in a subsequent release to clean up the code.
I am still inclined to favour solution #1 because it synchronizes the network and only requires a single upgrade. @sigmike are there additional bad side effects with option #1 that havenāt been discussed yet? Is option #2 an accurate description of your proposal? @mobydick, @ronny and other exchange operators, how do you feel about the two options?
1 Like