I estimate this will cost $2000 to code, test and deploy. If it were passed quickly, it could be included in the Nu 2.1 release.
This is mostly about how NuShares are presented to users, so others are just as qualified to decide if this is a good idea as I am.
On a technical level, there are no significant problems with doing this within the client. As noted in the original post, the main potential for problems regard changing external systems that use NuShares. Changes will need to be made to other wallets such as Coinomi. Any system that uses NSR in automated fashion will need to be changed as well. This primarily consists of exchanges, which will need to synchronize their update of the Nu client, their internal database update and possibly an update other internal code. The main danger is exchanges updating their client but not updating their internal NSR ledger. If someone has 30,000 NSR on deposit at an exchange and only the client is updated, then they would be able to withdraw up to 30,000 new NSR, which would permit them to withdraw 10,000 times too much value. So it is very important that exchanges divide the number of NSR in their internal databases by 10,000 as part of this upgrade. If this did go wrong at a particular exchange, it is possible for shareholders to cover the exchange loss if they chose to.
Because of the complications this creates for external systems, we cannot make this change later, once there is wider use of NuShares. This is our last chance to do this. Similarly, once it is done, it can never be undone. There will never be a stock split for NuShares due to the complications created for external systems that use NuShares.
This also makes B&C and Nu easier to maintain because they will have more similar code bases.
I believe the benefits of this change outweigh the risks.
