Immediate mandatory upgrade: Nu client version 0.5.4

[JordanLee]

Version 0.5.4 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.

[irritant]

is it possible to broadcast an alert to all the clients?
like https://en.bitcoin.it/wiki/Alerts

[JordanLee]

Alerts, client upgrades and checkpoints are all on the development roadmap to be implemented via decentralized data feeds. I didn’t want those things being centrally pushed, so no, a client alert is not possible.

[cryptog]

upgraded.

Version 0.5.4 contains a protocol change that will cause certain blocks produced by the older versions of the client to be rejected.

The question that I have is the following: can old clients (that contain the counting bug) still get their duplicated votes counted as multiple votes? If yes, the votes counts for the open sourcing motion would still be incorrect if some shareholders keep on duplicate their votes with the old client.

[Yurizhai]

Done

[JordanLee]

The question that I have is the following: can old clients (that contain the counting bug) still get their duplicated votes counted as multiple votes?

The problem was principally in how votes were counted, not how they were cast (though improvements could be made to both and casting duplicate votes will be prohibited as a matter of protocol in the 0.6.0 version). So old clients may continue to cast duplicate votes, but 0.5.4 will not count the duplicates toward the vote totals.

[crypto_coiner]

Upgraded

[cryptog]

I see. Tks for the clarification.

[masterOfDisaster]

Version 0.5.4 contains a protocol change that will cause certain blocks produced by the older versions of the client to be rejected.

@Coingame the RaspberryPi fraction (that is not much bigger than me, I’m afraid ) needs you and your ARMv6 binary version of nud to test version 0.5.4!

[desrever]

that is not much bigger than me

Oh no, I also joined the fraction and I am not the only one either

[Goye]

Hello, guys. How much time, i have, before old client will be absolutely not work? I not very big specialist in tech questions, just only trades, so, maybe need a help from support. Where can i ask for real-time help?
Thanks, in advance,

[woolly_sammoth]

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.

[Goye]

Thanks, Woolly, will try asap.

[creon]

The JSON object returned by getblock still contains duplicate motions.

[woolly_sammoth]

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

[creon]

Even after that, the blocks that contain the multiple votes will remain part of the blockchain

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.

[woolly_sammoth]

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.

[cryptog]

Yes. Confirmation from jordan lee here.

[JordanLee]

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.

[desrever]

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