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.
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
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.
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.
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.
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?
@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.