Immediate mandatory upgrade: Nu client version 0.5.4

Hi @Goye, There’s no hard set date, but it is in the best interests of the Network for everyone to update as soon as they can to avoid a disorderly fork

This version contains a protocol change that will cause certain blocks produced by the older versions of the client to be rejected. However, the old clients will under all circumstances accept a block from the new client. Therefore, version 0.5.4 will fork at an unknown time in the future. When it does, if the majority of minting power has upgraded, old clients will join the 0.5.4 fork without incident. If the majority of minting power has not upgraded, there will be a disorderly network fork. Therefore it is of paramount importance that a comfortable majority of minting power upgrade before the fork occurs. Please do your part by upgrading right now.

To upgrade, all you need to do is download the new version and run that instead of the nu client you currently run. All your wallet information is held separately to that and will be picked up by the new client.

2 Likes

Thanks, Woolly, will try asap.

The JSON object returned by getblock still contains duplicate motions.

it will until the ability to add duplicate motions is removed from the UI in version 0.6.0. Even after that, the blocks that contain the multiple votes will remain part of the blockchain and will show as such in the getblock output.

The important factor is that the RPC command to count the motion votes only counts them as a single vote

1 Like

The question is if they should be included in the JSON object. But I begin to understand why you want to enforce this on protocol level and not just in the parser - there are many unforeseeable effects if someone implements this wrong.

I think they should be included in the JSON Object as that should reflect the true state of the block in the blockchain which does, in this case, contain multiple votes.
That’s just my 2 pence though.

Yes. Confirmation from jordan lee here.

Currently, adoption of mandatory upgrade 0.5.4 is around 55%. That is not enough for us to be safe when the fork occurs. Please upgrade now if you haven’t already. Eventually we will automate updates by driving then with data feeds, but today it is manual.

Open sourcing the code will precipitate the network fork we are expecting, so not updating is delaying opening of the source code (within our 45 day window to open it). It is also delaying our release of the builds for OS X and Raspberry Pi.

Edit: There will only be a network fork if the 0.5.4 client does not have wide adoption, because old clients will always accept a 0.5.4 block, but 0.5.4 clients will not always accept a 0.5.3 and older block.

This topic is now a banner. It will appear at the top of every page until it is dismissed by the user.

We will make Raspbery Pi and OS X builds when 0.5.4 adoption reaches 65% as indicated by the connected nodes reported by the block explorer.

Latest figures indicate adoption is now 60%.

1 Like

Counting only peers with a last relay of 2 minutes or less we get

20 peers with v0.5.4
1 peer with v0.5.3
3 peers with v0.5.2
8 peers with v0.5.1

So while we probably reach the 65% you are asking for once the 3 OSX people shut down their wallet, the people who are actually disturbing consensus are those with v0.5.1.

Unfortunately these people also didn’t consider it as necessary to update before v0.5.4 so I don’t have much hope that they will do so this time. Of course measuring the number of connected peers is not a very good estimate. Writing the version into the coinbase string (like a motion) would be interesting, and also would allow to “simulate” hard forks without actually doing them.

I updated on v0.5.4 on 2/21
Looking today in my wallet today, it shows that I have not minted a block since then.
What’s the issue?

This is the first I have heard of anyone having a problem minting with the build. Do you mint using the Settings…Unlock Wallet for Minting Only toggle button? If so, does the lock icon appear selected or pressed? Does the lock or unlocked icon appear in the lower right of your client? If you would, post the following results returned by the getinfo RPC: version, blocks, connections, unlocked_until and testnet. Be aware the complete getinforesults contain your IP address, balance and stake, which you probably don’t want to share. To return the getinfo results, ensure that NuShares are selected under the Unit menu, then select Help…Debug window. In the command line that appears type getinfo and press enter.

Do you see stale blocks (unconfirmed blocks) in your Transactions list during the last two days?

Edit: is your wallet encrypted?

1 Like

Yes

Yes

Yes

getinfo:

{
“version” : “v0.5.4-beta”,
“protocolversion” : 50000,
“walletversion” : 1,
“walletunit” : “S”,
“balance” : ************,
“newmint” : 0.0,
“stake” : **,
“parked” : 0.0,
“blocks” : 237617,
“moneysupply” : 1009452578.1434,
“connections” : 8,
“proxy” : “”,
“ip” : "
",
“difficulty” : 0.00038188,
“testnet” : false,
“keypoololdest” : 1417421047,
“keypoolsize” : 101,
“paytxfee” : 1.0,
“unlocked_until” : 0,
“errors” : “”
}

My Wallet is encrypted

“unlocked_until” : 0,
while
"errors" : “”

That’s odd!?

That’s normal when unlocking via GUI.

@crypto_coiner: Make sure that you don’t have any duplicate motion in your voting. The GUI still allows to do so and if those motions are also written into the coinbase string then you won’t accept your own blocks.

Do you see anything odd in your debug.log file? It’s located in the data dir.

Ah. I didn’t know that. I’m always using command line.

I MAY HAVE DUPLICATE MOTIONS IN MY VOTING LIST INDEED - will check tomorrow (dont have access to my client right now)

@JordanLee would it be possible to clarify why you’re waiting to push new builds for OS X and RasberryPi?

1 Like