Nu 3.0.1 release with new currencies

I uploaded Nu version 3.0.1 to the repository, according to my proposal and the details discussion.

You can download it there:

A new protocol version 3 was added. It will become active at 14:00 UTC 14 days after 60% of the last 2000 blocks have been generated by this new version.

After this protocol activates shareholders will be able to issue custodian grants on the 3 new currencies: CN-NBT, EU-NBT and X-NBT (the NuBit currency being renamed to US-NBT). The new protocol will also accept unknown currencies, so that adding other currencies will not require a new protocol change.

The changes are:

  • imported the signature fix from peercoin
  • imported miniupnpc fix and disabled UPNP by default
  • imported the protocol switch system from B&C Exchange
  • imported the -debugmint option
  • added the 3 new currencies
  • added a -initialunit option to make the GUI open a specific unit at startup
  • in the GUI, removed the button after the tabs to switch between units, and replaced it by a click on the current unit logo
  • added the ability to display the park rates and liquidity info of the new currencies in the vote tab
  • updated the parking rate calculation to supported other currencies
  • added tests of various parts to make sure they work with the new currencies
  • allowed unknown currencies in the protocol and made sure the client works fine when it encounters one

I created a 3.0-stable branch on the repository. You can check the changes against the previous version 2.0.3 here: v2.0.3
Note that the master branch on the repository is still on 2.1, which is not part of this release.

sha256sum of the files built with the gitian process:

6e6f19b708390f86e4397769b32f1436bded9a5c8d8273b993919a844224fec2  bin/32/nu
9bc629a0bb7fea2cf0890d19d1e559e7c030197cfdf75c4a2173544fea6496f3  bin/32/nud
d8ba674e596a81a3396d324bd5cc6b882a5f1215be42569c64eb426b2e14df8a  bin/64/nu
11231639eb67f603f0112ef79ae8e8462d07d91806aba0e744bf655ddad6eeae  bin/64/nud

0acfea7a008667a37b3c11b0c14023be32f6bb19126f7be6bdefaadcf14e34c3  32/nu.exe
ad52b5e91581e2ffb4e070ec06313bcc8e1a6c2c8ec894c30a009b09e6bca76a  32/nud.exe
9dd678bfe293b62043efbb7d65e2866fc56eae976ae1afda6fd293e6bd84ef1a  64/Nu-3.0.1-win-setup.exe
f1e64590b1fd75592d1ca5c1f2f46904868623021f92a692beac34cd7ff8122a  64/nu.exe
21bae7fa9c69393e6dbc09b84599c963d1afd9f7b66449fafc5cf3053eaa0d65  64/nud.exe

here’s macosx build of Nu v3.0.0

sha256: 3520f6203c042e5fa8c2d07102b974821ed1a3b4f5f1c991db4efed400258263


From an economical point I have doubts about that version, but respect the coding and the client releases.

I’m very pleased to see this. @woolly_sammoth what remains to be done to adapt NuBot to 3.0?

The next step will be finding exchanges that will list CN-NBT. After the protocol change occurs, I will request the first grant of CN-NBT. Once we have this grant and the NuBot changes, we will be prepared to support trading pairs on exchanges.

Who wants to step up to lead this important marketing task?

I think we should really push exchanges to place CN-NBT as the denominator, not the numerator as is the case with US-NBT on Poloniex. This improves the readability of our price.

Finally, with the OP @sigmike has met the requirements for receiving a rapid deployment bonus. Having met the requirement on the the 30th, that qualifies as a 14 million NSR bonus as I recall. Is that what you were expecting @sigmike?


I’m having intermittent issues with the Linux 3.0.0 client. The first time it appeared to be stuck at:

“blocks” : 1120769,

Had to restart the client and it now appears to work.
Might be a coincidence but blockexplorers are also not working. Is it just me?

V2.01 client still works, although I noticed that there are unusual large gaps between the blocks at times (e.g. 7 minutes) or large reorgs, meshing issue, not sure. Haven’t seen that before with this blockexplorer. You can see it here: Maybe it is not v3 related, it seems to be going on longer than that.

Anyway, will start minting with the new v3.0.0 client.

Should I add it to the download page?

That’s how I understand the bonus rules yes.

I didn’t change anything related to the download in this version, so I think it’s not but it’s still possible.

Something is not right. V3.0.0 reports up to date while it is multiple blocks behind. It doesn’t seem to catch-up. It is now 25 minutes behind. When I start V2, it catches up. Restarting v3.0.0 recognises the updates but won’t progress by itself.
Curious to hear whether others have better results.
Edit BTW, the test env also seems to have stalled at block 612665 even though I still have a v2.1.1 client running with 2 peers. Can you confirm that? @sigmike

I’ll check that.

Indeed my client was not minting anymore. It is now, and it has already found some blocks. It’s still on 2.1 though. I’ll start a 3.0 client.


That works!

Indeed there’s a problem with the park rate calculation. I will certainly have to make another release. Do not upgrade yet.

I’ve made a fix:

I’m testing a full chain download and when it’s done I’ll release version 3.0.1.


The full download test was successful. I found another problem that I fixed though. The changes between 3.0.0 and 3.0.1 are here: v3.0.0

I updated the first post and


sha256: d721889cc1988c8058e150ab9730333a54687db27ba4a9d69c388d8234799205


What is the current rate of adoption of Nu 3.0.1?

When I look at the number of nodes I’m connected to, I see 4 out of 13 nodes on v3.01. Just over 30%. For the protocol change it is about the % of minters and their stake though. I don’t know how to obtain those figures.

Right now: 41.55% of the last 2000 blocks.

Testnet will switch at 2016-11-25 14:00:00 UTC.

When I imported the protocol switch code from B&C I also imported the getprotocolvotes RPC that will give you these numbers.


The protocol vote passed. The new protocol will be activated at 2016-11-28 14:00:00 UTC.

I made a mistake though. The protocol switch was triggered when 55% of the blocks were generated by this version whereas I proposed 60%. I guess when I imported the B&C code I planned to change the percentage after my proposal has been discussed, but when the final release came and there was no discussion about it I probably assumed I already had put the proposed percentage so I didn’t update it.

Given this percentage did not raise any discussion, that the numbers are not very different and that the absolute requirement to switch is 50%, I think it’s better to keep it that way. All the other options would probably result in a fork between shareholders wanting to switch and the others anyway.

Well, I suppose it won’t hurt to advance the date a bit. We just have to make sure that more than 55% of the block continue to be on v3.01 to prevent a fork I believe. Is that correct?

No, a fork would happen only if some minters decided to reject some block from the other side (by running a different client). Since only those who don’t want to switch may want to do that, and given they are a minority (although this is fluctuating) they would just fork themselves out. Now that the switch has been triggered it will happen at the planned time. The only way to prevent it would be that a new majority build a higher chain starting before the vote passed, or that the majority decides to run a client with different protocol rules (but if they happen to not be the majority they will just be forked out).

So that means more than 50% of the minters must be running on 3.0 for the network to stay healthy. So 55% is actually a good target.


I suppose it is now secure the do the upgrade. I ll do tmr.