New currencies development proposal


#1

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.


New currencies details
Nu 3.0.1 release with new currencies
#2

I’m very pleased to see @sigmike’s proposal. It has my strongest support. While the release will be sigmike’s responsibility and he won’t be reporting to me, I will do whatever I can to help make the release a success.

Regarding the options listed in the OP, I prefer to not pay to have these changes ported to Nu 2.1 because it isn’t clear it will ever be necessary to do so and if it does become clear it is needed, it can be done then. I would like to see the release permit the release of other currencies not yet planned with only an optional client update, not a hard fork. In regard to paying for a new testnet, we ought to first determine if the existing one is usable. We need a testnet, and if the existing one can’t be used, then we need a new one. @Ben and @CoinGame what can you tell us about testnet and its supply of NuShares?

There is the matter of paying for this. I am not comfortable that it is permitted under the terms of the latest liquidity operations custodial grant. It would either need to be funded by @masterOfDisaster or a custodial grant. The question then becomes who should hold the key(s) to the custodial grant. There are three options worth considering that I see: sigmike, myself, and a 2 of 4 address. I would accept myself, @jooize, @Cybnate, @henry, @cryptog or @woolly_sammoth as signers.

I will be releasing a custodial grant request to pay performance bonuses for peg restoration soon. I plan to include an incentive for fast deployment of this release in that bonus package. It would be something like a 15 million NSR bonus for release in 2 weeks, with the bonus declining half a million NSR each day.


#3

Support your ideas, if you can, I am willing to pay $100 worth of NSR support your work.


#4

Excellent proposal.

I do have testnet shares (25m) and testnet NBT (600k) and just fired up the client to see if there are still some peers. Currently just 1 but not syncing (I’m at block 362666). Feel free to fire up one, maybe we can get it going. I know that Coingame had the majority of shares, but if that is lost I suppose we could distribute my testnet shares to kickstart a few minting clients.[quote=“sigmike, post:1, topic:4615”]
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.
[/quote]
However if this is a problem stopping or slowing down development, I suggest we pay the cost for an improved testnet, as it should pay itself back for this development, testing and anything thatfollows. Having a robust testnetwork is underestimated I believe.

I believe raising a grant for the entire proposal is the most transparent way to go. I’m comfortable being the sole custodian on behalf of the shareholders as I have been for NuDroid and liquidity dealings in the past or being part of a multi-sig group. I’m also about to burn over 10k of NBT funds in the next week or so from discontinuing liquidity provisions on Poloniex and Bittrex. So instead of a custodial grant a motion could also be raised and I can shift the money into a specific address for funding this development on behalf of the shareholders.


#5

We will effectively need 100 million to pass a custodial grant. This is a good start. Anyone else with testnet NuShares?

I’m going to see if we can make progress quickly on the multisig approach. Can we get four of the following individuals to volunteer to be in the signing group?:

@jooize
@Cybnate
@henry
@cryptog
@woolly_sammoth

I will volunteer only if there are exactly three other volunteers.

Feel free to propose and discuss signer compensation. I will propose three percent of funds disbursed be split among the signers. This should be regarded as a pilot study of using multisig management of dev funds. The group may be used on an ongoing basis to manage dev funds.

I am hoping we can get a multisig custodial grant request published in just a day or two so sigmike can get started quickly. Let’s see how fast we can move this forward.


#6

are you planning to do all the work yourself or distribute the tasks between willing developers?


#7

I am interested in being a signer for the funds that would pay for the development done by sigmike.


#8

i am interested in being part of signing group also


#9

I am happy to work for Nu as a signer.

me too.

Nu 2.1 was supposed to improve Nu’s memory usage and solve many other issues. It took too long and hasn’t officially delivered yet. If we can deliver 2.1 without more delay on this time’s release, I would support pay extra fee to do it.

@sigmike, have you ever considered to accept payment in NSR? According to NSR’s current market price, you can take over 2% of shares by finishing this job. I guess it benefit both you and Nushareholders if you can be a big shareholder of Nu.


#11

I can sign.

I would benefit from lower memory usage.


#12

So @jooize, @cryptog and @henry are willing to be signers of a US-NBT grant for development. Good. That leaves @Cybnate and @woolly_sammoth that we are looking for responses from.

I’m hoping one of you will take the initiative to create a corporation or partnership to encapsulate your activities.


#13

In the meantime I found a testnet wallet with about 70m testnet NSR. My node just finished loading the old wallet and I started minting. So the current testnet seems to be working.

The previous block was from the end of 2015, so I patched my client to slow down minting because the difficulty is going to be so low that it may lock the shares too quickly.

If nobody else is minting we should only need a small number of shares.

It’s not stopping and should not slow down development. Testing may be a little longer when a full blockchain has to be downloaded, but it would not be a lot faster with better settings. These settings were really a problem when I tried to fix download issues in Nu 2.1.

I evaluated the costs and delays considering I would do all the work. I may be willing to delegate some parts if it doesn’t hinder the development.

The 2.1 changes in this proposal are only about the new currencies, not about resolving 2.1 issues. I don’t know how much work is needed to finish 2.1.

At this time I am not interested in being paid in NSR.


#14

Maybe we should take this into another thread, but I can connect to your client (based on the version number) at height 568984, but mine won’t sync with it for some reason. Even tried with an older chain. Any ideas why? (maybe via PM?)

I’m good to join a multisig for development funds with a payment frequency not more than once a fortnight on average.


#15

It may be because I’m running 2.1. I’ll start a 2.0 node.


#16

Just started a sync from scratch. That works, but chain shows only 284515 blocks under information in gui, while with getinfo I get the earlier mentioned blockheight. Would be odd if a 2.0x client works, but worth trying I suppose.


#17

Excellent, we have four qualified volunteers for a new multisig group to fund NuBit development. @cryptog, @Cybnate, @jooize and @henry will you please proceed to create a 2 of 4 US-NBT address and a custodial grant proposal that includes a mandate to fund sigmike’s work and possibly fund other development. 20,000 US-NBT might be a reasonable initial grant amount.

Questions or concerns?

One matter that needs to be spelled out is signer compensation. I trust you can come up with a plan.


#18

Wow!
New currencies to collect new assets instead of working on revenue.
The greater fools game gets extended from NSR to CN-NBT, EU-NBT and X-NBT.

People, wake up - without revenue the new currencies will not save Nu, they will just postpone the end, leaving more cheated people behind.
You still don’t find a pyramid scheme here? Seriously?

But I bet that not having accounting makes it easier to keep believing…


#19

I am hoping we can make quick progress on this. It is currently THE blocking item preventing progress on releasing additional currencies. If nothing happens soon, I will need to devise a work around.

Don’t like all the power I have? Want decentralized management of funds? It is time to step up and do something. Otherwise, I have no choice but to do it all myself.


#20

Give us all a break here. You hand picked the candidate signers, own enough shares to elect yourself, and ignore everyone who has a disagreement until they get fed up and leave Nu. You are the driving force behind the centralization of Nu and we are all helpless to do anything about it (except buy out your shares from the orderbooks). You should read your own white paper and then take a look at what you have turned Nu into.


#21

It looks like Nu already had that and @JordanLee ended it.
Mission accomplished, right?

Thank you for reminding me of that!
I was dearly hoping for helping Nu to evolve and become shareholder.
It’s over when it’s over…