Mandatory upgrade to Nu 2.0 by August 25th

I successfully upgraded. If any of you have been using a data feed, be sure to open it up and look to see if the checkbox for the transaction fee is checked. It was deselected when I looked at mine.

sha256sum of the files I generated:


1 Like

The master branch of is not on 2.0, right?

I compiled from master and get:

nud getinfo
    "version" : "v1.2.0-4-ga544017-dirty-beta",

ninjaedit: I think I might delete this post soon, because I’m a git noob:

git checkout 2.0.0-Stable-Release
make -f makefile.unix

…still running

edit: done

nud getinfo
    "version" : "v2.0.0-dirty-beta",

Indeed it was in the 2.0.0-Stable-Release branch but not yet in master. I just merged it.

1 Like

Will see if i can make an unofficial raspberry build later tonight

    "version" : "v2.0.0-beta",
    "protocolversion" : 50000,
    "walletversion" : 1,
    "walletunit" : "S",
    "balance" : 0.0,
    "newmint" : 0.0,
    "stake" : 0.0,
    "parked" : 0.0,
    "blocks" : 480314,
    "moneysupply" : 1007495950.20239997,
    "connections" : 28,
    "proxy" : "",
    "ip" : "masked",
    "difficulty" : 0.00032577,
    "testnet" : false,
    "keypoololdest" : 1438648168,
    "keypoolsize" : 101,
    "paytxfee" : 1.0,
    "errors" : "EXCEPTION: St12out_of_range       \nCInv::GetCommand() : type=3 unknown type       \nnu in ProcessMessages()       \n"


This error is what I get when I query nud with “getinfo”…

Will this update automatically on daemons when the feed sets a tx vote or is further action required?

This is an error triggered by a node sending invalid messages. The error is not correctly handled by the client, hence the odd display here, but it’s not something to be worried about (besides being connected to a strange node). We will fix that in the next version.

The behavior on upgrade is not to change your data feed settings. Do you think the upgrade should automatically add the new parts?

It’s the same as the GUI, your settings won’t include the new parts after the upgrade. You can check with getdatafeed.

If you defined your data feed without specifying the parts, then you can just do it again after the upgrade, because the new default parts includes the fees:

    setdatafeed <url> [<signature url> <address>] [<parts>]
    Change the vote data feed. Set <url> to an empty string to disable.
    If <signature url> and <address> are specified and not empty strings a signature will also be retrieved at <signature url> and verified.
    Parts is the list of the top level vote parts that will be taken from the feed, separated by a coma. The other parts will not affect the vote. Default is "custodians,parkrates,motions,fees".

Okay, so I just have to re-add the feed. Does it matter whether the feed already has tx vote data set or not?

No. If the data feed doesn’t provide the fees part then your fee vote won’t be changed. If it provides it (and you enabled the fees part), then your fee vote will be updated like if you did it yourself. In any case your fee vote won’t be included in your blocks until the protocol switches to 2.0.

Okay. Re-added my data feed

“parts” : “custodians,parkrates,motions,fees”

obviously worked.

How to compile it on Ubuntu ? I get

In file included from scanbalance.cpp:5:0:
db.h:17:20: fatal error: db_cxx.h: No such file or directory
compilation terminated.
make: *** [obj/scanbalance.o] Error 1

i found

sudo apt-get install libdb++-dev

very helpful

1 Like

You beat me to it. I was already answering :stuck_out_tongue:
On my RPI I have 5.1 installed and that worked fine:

dpkg --get-selections | grep libdb
libdb5.1:armhf                                  install
libdb5.1++:armhf                                install
libdb5.1++-dev                                  install
libdb5.1-dev                                    install
libdbus-1-3:armhf                               install
libdbus-glib-1-2:armhf                          install


This might look unrelated at first glance, but in fact it’s one of the main differences between PoW and PoS systems; another difference that makes Nu so much more sustainable than PoW solutions and not only in terms of energy efficiency.

Nu and BCE inherited that powerful difference from Peercoin.

What’s happening at Bitcoin at the moment ( can’t happen at Nu, from version 2.0 on even on protocol level.
The people who own the shares (and hence a big financial stake) and the people who secure the blockchain, process transactions, create blocks, are the same entity!

They have the right and the power to decide.

I sincerely admire @JordanLee’s farsighted design!


Note that a wallet created with this version of the library will not work on the official build. It’s not a problem if you intend to always use the wallet with this version (or a later one), but if you ever have to run the official build it won’t be able to read your wallet file.
See this message for an explanation:

You can use the bitcoin ppa to get the libdb4.8+±dev package that is compatible with the official build:

Ah, the wallet file… then I create a new blank one :wink:
Thanks for the advise anyway!

I just tried to compile a new version of nud and was about to install the repo ppa:bitcoin/bitcoin, but the packages there are not for ARM CPUs.
I’ll have a look at where to get the BerkeleyDB 4.8 to make a compatible nud on my RPI.

Thanks for the hint! I’m sure it saves me plenty of time compared to not knowing about the mess I did with compiling nud using libdb5.1 and facing unexpected trouble!

Here’s some snippets for those who want to build nud on the RaspberryPi with BerkeleyDB4.8 (and don’t find a repository with compiled libdb).
I suggest to remove libdb5.1 (or whatever is installed) first - I don’t know which version is going to be preferred if both are installed.

cd ~/
tar xvf db-4.8.30.tar.gz
cd db-4.8.30/build_unix
../dist/configure --enable-cxx
sudo make install

Sorry if this has been mentioned in a post already but from what I could see there’s not been a successful build on a raspberry pi yet?

Otherwise I might have to temporarily put my NSR on my mac then transfer back when there’s an RPi build.

Of course there are successful builds - e.g. mine.
But as I compiled it using BerkeleyDB5.1 it converts the wallet files and makes them incompatible with official builds (that are built with BerkeleyDB4.8).
That’s what @sigmike was referring to.

If you just want to compile it and run it and don’t have to care for wallet files, then it’s easy on RaPi.
Building nud it with BerkeleyDB4.8 is a bit harder, because it can’t be found in the standard repo (and in no trustworthy repo I’m aware of) and needs to be installed manually.

This output is from my RaPi2:

I think the version is “dirty-beta” because when I cloned the source code from github, 2.0 wasn’t yet in the master branch and I had to switch to checkout the 2.0.0-Stable-Release branch.

Hey thanks for that. How do you mean it makes the wallet incompatible though? Do you mean it’ll ruin the current wallet and I’ve just got to resend the NSR to the newly compiled version 2. Or do you mean that the wallet simply doesn’t work?