The recent relative increase in my available time and the community peacefulness allows me to make a proposal for the development of the new currencies implementation in Nu.
Proposal
Here are the changes I propose to make to add the 3 new currencies CN-NBT, EU-NBT and X-NBT as discussed here:
- Change all mentions of the NuBit currency to US-NBT
- Add the new currency units (similar to the current ‘B’ for US-NBT and ‘S’ for NuShare)
- Add the new address versions. We need 6 new versions for each currency (address, script, and private keys, for the main network and testnet). They will determine the first letter of the addresses of the new currencies
- Add the 3 new wallets to the client
- Update the GUI:
- Add the name of the new currencies
- Enable switching to the new currencies
- Integrate the currency colors and logo when the corresponding wallet is active
- Enable voting for the new currencies park rates and fee
- In the vote tab add the liquidity info and the voted park rates of the new currencies
- Import the protocol switch system from B&C (with the switch occurring 2 weeks after a percentage of blocks have been generated by upgraded clients)
- Add protocol v3
- Make the new currencies valid only when the new protocol is effective (although in anything not protocol-related they will be valid immediately)
- Add functional tests to verify parking and grants on the new currencies work like on US-NBT
- Change the unit tests that checks behaviors on US-NBT to also check on the new currencies
- Handle multiple currencies in the park rate calculation (it’s the only part in the protocol code where support for multiple currencies was not implemented from the beginning, because we lacked time and it was not very difficult to add it when needed)
- Allow liquidity info for all currencies
- Enable fee voting on the new currencies when the protocol has switched (this will require default values for minters who do not have an explicit vote for them)
- Update miscelaneous messages that only mention US-NBT
- Fix upnpc compatibility and disable it by default (it was done in 2.1 but not in 2.0, and it makes build fail on recent systems)
- Make release candidates as necessary, and the final release (Windows and Linux)
For all the decisions that need to be made (like address versions or default fees) I plan to make proposals on the forum, discuss them with the community and then make the decision.
If shareholders disagree with my decisions or want to change anything in the contract they will have to settle that with a motion. If I cannot comply with the motion (for example because it increases significantly the development costs and the motion does not provide additional funds) the contract will end and any development already made will have to be paid (I will provide the percentage each of the above tasks represent on the total so that this amount can be determined).
These changes will work on testnet but I don’t know who holds shares on this network so I’m not sure we will be able to test it there. I have added an option below to start a new testnet.
The changes will be implemented on the Nu 2.0 code. I’ve added an option below to also implement it on Nu 2.1.
Payment
The cost for all these changes is USD 10’300. I estimate to be able to complete them within 60 days.
I ask for a payment of 30% when the proposal is accepted, then another 30% when half of the development has been merged into the repository, and the remaining 40% up to 30 days after the final release (so that shareholders have enough time to make the protocol switch and issue new currencies to verify everything works).
Payment can be made in NBT if the peg is stable (at USD 1.00, with at least 3 times the paid amount on the buy side on Poloniex, and no recent peg failure) or in BTC (at the coinmarketcap price when the milestone is reached).
Options
Here are some optional additional changes:
Nu 2.1
Port all these changes to Nu 2.1, which I suggest we rename to FutureNu or something, and make it follow the same versioning as the main client (they would both be 3.0) until they are merged.
The cost is USD 1200.
Allowing future currencies
@Phoenix thought that adding these currencies would not require a protocol change. It’s not the case but it could be. In the new protocol we could allow unknown currencies at the protocol level, and make the client handle them correctly.
Currencies are currently defined by an “unit” which is an 8 bits number (with only the ASCII codes for ‘B’ and ‘S’ being currently used). At the protocol level we can allow all the 256 codes with very little changes. At the client level the biggest change is to handle the addresses of unknown currencies because we cannot generate them and there are many parts in the code that won’t work without valid addresses. If we allow non printable ASCII currency units then some code will also need to be changed.
So I’d suggest we only allow printable ASCII currency units (or even only uppercase letters to avoid confusing units like ‘b’ or ‘:’) and just make enough changes so that the client does not crash when it encounters transactions in an unknown currency. Adding new currencies would then only require a new client for the shareholders who want to issue them and the users who want to use them.
A default fee for all the future currencies would also have to be decided.
I estimate the cost to be USD 1200. But some code may be difficult to adapt to unknown currencies and it’s very hard to know that before actually trying, so this cost may be subject to change. Shareholders will be notified in advance if that happens and will have to decide whether they proceed with the new cost or stop there and pay only what has already been completed.
Starting a new testnet
I don’t know if the persons who hold shares on the current test network are still around so I’m not sure the protocol can be switched there. So if shareholders want to test the protocol on testnet first we may need to start a new testnet and distribute the shares to new testers. The current testnet also has some settings that are different than the main network and that makes testing less relevant. And there are also some bad settings that are making the initial download speed worse than on the main network.
We may also want to make the protocol switch faster on testnet (for example 2 days after the vote instead of 2 weeks).
The cost is USD 1400 to:
- start a new testnet with better settings,
- generate the new testnet shares,
- make the previous protocol switches happen to match the state of the main network,
- change the protocol v3 switch time to 2 days on testnet,
- distribute shares to people who want to test the new protocol (if any)
- and test the new currencies on this new testnet (issuing them, changing fees, transferring amounts, parking).
After some discussions here I’ll hash the proposal and each option so that shareholders can vote. I’ll start working on it after I’ve received the first payment.