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?
