Delegates and seed nodes, upgrade your client version to 0.4.1

[DACSunlimited]

0.4.2 is coming soon, all delegates need to update it.

https://bitsharestalk.org/index.php?topic=7067.0

[emski]

Just a note to anyone interested:
I'm on 0.4.1 since a few hours after it got out.
no crashes.
no missed blocks.
no restarts.

[vikram]

A round consists of 101 blocks (not timeslots). Assuming you have only 1 active delegate, once you produce your first block 1 <= k <= 101 in the round, you will either produce after the next shuffle or produce again in the same round if many others are missing blocks. In both cases, the exact time of your next production is unknown until at least (101 - k) time slots have passed.

The get_info output tries to reflect this uncertainty in a somewhat user-friendly way by printing "at least ..." when appropriate. This is purely a display enhancement and does not affect the actual scheduling of block production.

I did find a bug in the display calculation which I've fixed: https://github.com/BitShares/bitshares_toolkit/commit/4d67f6fcf34ea7e382a929696adb970509ee7614

[liondani]

Just for the records after installed version cli 0.4.1  (on linux)
no missed blocks, no freezes, no crashes until now...

PS only very often  "wallet_next_block_production_timestamp": null
     but it not resulted any missed blocks or other problems...

PS1 The only question is: am I producing less blocks compared to delegates that are on the older versions due to this NULL thing (for "wallet_next_block_production_timestamp")? Could it be possible?

[bdnoble]

I guess this is because you have produced the block in this round, and there will be a shuffle before you produce next block, so the program can not calculate exactly time when you will produce your next block

This is not how it works... you can produce multiple blocks in a single round if someone misses.  So that is not why it is NULL.

That said, I think this thread should be updated to reflect that delegates should not upgrade unless they want to help test and are prepared to upgrade one more time before wednesday.   Delegates that want to be lazy and upgrade only once should not try this release.

After discussions going on I have tweaked the bitasset FDIC system so the hardfork will be slightly different than we see in this release.  In fact, we may want to push the hard-fork back a few days so that all the issues can be worked out.

I don't understand. If that isn't how it works, then how does it work? Because it always says NULL until the next round begins now.

Also the time being 1910 is from making your unlock time too long. 9999999999 is too much but 99999999 is fine and puts it to 2017. That has been the case since before 0.4.0 though.

[HackFisher]

I guess this is because you have produced the block in this round, and there will be a shuffle before you produce next block, so the program can not calculate exactly time when you will produce your next block

This is not how it works... you can produce multiple blocks in a single round if someone misses.  So that is not why it is NULL.

I remember this was changed because if every delegate running well (no missing blocks), the original implementation is telling the wrong time. This could explain the current report as "NULL" of next producing time.
"wallet_next_prodution_timestamp_in_current_round" maybe make more sense as bytemaster described.

Have no idea about the "wallet_unlocked_util_timestamp".....

[bytemaster]

I guess this is because you have produced the block in this round, and there will be a shuffle before you produce next block, so the program can not calculate exactly time when you will produce your next block

This is not how it works... you can produce multiple blocks in a single round if someone misses.  So that is not why it is NULL.

That said, I think this thread should be updated to reflect that delegates should not upgrade unless they want to help test and are prepared to upgrade one more time before wednesday.   Delegates that want to be lazy and upgrade only once should not try this release.

After discussions going on I have tweaked the bitasset FDIC system so the hardfork will be slightly different than we see in this release.  In fact, we may want to push the hard-fork back a few days so that all the issues can be worked out. 

[HackFisher]

Delegates are still free to upgrade but must be aware that there a crashing issue has been identified.

Upgraded but have make one weird observation...

at some time:

"wallet_unlocked_until_timestamp": "1910-03-19T05:05:04",

"wallet_next_block_production_time": "at least 70 seconds in the future",
  "wallet_next_block_production_timestamp": null

after the time has past for wallet block production my wallet don't produced the block....





EDIT:

it happens often to see now:

"wallet_next_block_production_timestamp": null

I guess this is because you have produced the block in this round, and there will be a shuffle before you produce next block, so the program can not calculate exactly time when you will produce your next block

[liondani]

Delegates are still free to upgrade but must be aware that there a crashing issue has been identified.

Upgraded but have make one weird observation...

at some time:

"wallet_unlocked_until_timestamp": "1910-03-19T05:05:04",

"wallet_next_block_production_time": "at least 70 seconds in the future",
  "wallet_next_block_production_timestamp": null

after the time has past for wallet block production my wallet don't produced the block....





EDIT:

it happens often to see now:

"wallet_next_block_production_timestamp": null

[puppies]

I've got my seed node and webwallet running on 0.4.1 with gdb enables.  I am still a little squirrelly about my delegate node after my experience with 0.3.0.   

[emski]

No crashes except some missed blocks on 0.4.0 for more than 12 hours.

[Riverhead]

Is the crash issue rearing its ugly head outside of delegate operations?  Would upgrading my webwallet and public node and running under gdb help?

We have only 2 reports of crashes, both on operating delegates. It would still be helpful to run other clients in gdb just in case the issue still manifests until we are confident about stability.

Nice and stable so far here but I'll give it a shot running in gdb. Anything you need set that I should know about before hand?

[vikram]

Is the crash issue rearing its ugly head outside of delegate operations?  Would upgrading my webwallet and public node and running under gdb help?

We have only 2 reports of crashes, both on operating delegates. It would still be helpful to run other clients in gdb just in case the issue still manifests until we are confident about stability.

[puppies]

Is the crash issue rearing its ugly head outside of delegate operations?  Would upgrading my webwallet and public node and running under gdb help?

[Riverhead]

0.4.1 running without issue.