BitShares Forum
Main => General Discussion => Topic started by: DACSunlimited on August 15, 2014, 01:49:14 am
-
0.4.1: Fixes missed blocks problem due to hardfork changes.
*This is a version only for delegates, exchanges, and seed nodes.*
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.
Updates from bytemaster:
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.
Do not publish price feeds until after hardfork and all clients are upgraded. This is a new operation that is part of the hardfork. All old clients will reject blocks containing publish price feed operation. This is the reason for missed blocks.
Large transaction and block sizes are also part of the hardfork, and could result in missed blocks.
We will release a patch ensuring all hardfork changes take effect at the same time.
Delegates are still free to upgrade but must be aware that a crashing issue has been identified. Brave delegates can upgrade and run client in a debugger to help us get a stack trace of the crash.
GUI will be provided soon. All clients must upgrade before hardfork or syncing will freeze.
Download and build from:
https://github.com/dacsunlimited/bitsharesx/releases/tag/0.4.1
Suggestions:
1. Active Delegate, be careful and make sure you are producing blocks during upgrading.
2. Delegates, publish your price feeds.
Refer bytemaster's post about price feeds:
https://bitsharestalk.org/index.php?topic=6306.0
Change Log
- [HARDFORK] Block 274000 - Old clients will no longer sync after 2014-08-20 15:30:00 UTC
- [CHECKPOINT] Block 225000 - ID: 2e09195c3e4ef6d58736151ea22f78f08556e6a9
- [EXCHANGES] wallet_transfer API now returns a wallet_transaction_record which includes the transaction ID
- Database will re-index on launch
- Market has been overhauled and market-pegged BitAssets have been added
- Max block size increased from 2560 bytes to 51200 bytes
- Transaction size limit has been removed
- Size-based transaction fee requirement has been removed
- Wallet will no longer automatically relock if it contains any enabled delegates
- Chain server mode has been added to allow for improved initial syncing speeds
- Block and transaction broadcasting fixes
- General syncing fixes
- NTP initialization fixes
- Miscellaneous fixes and improvements
-
- Market has been overhauled and market-pegged BitAssets have been added
O=
=O
||
O
-
What if we aren't savvy enough to build? Are you going to eventually release a compiled version for windows? And the link on price feeds didn't explain all that much on what to do.
-
market function is active??? :'(
-
one can count the hours to release now :) exciting
-
I updated and everything seemed to work properly.
As soon as I published price feeds I started missing blocks.
emski (unlocked) >>> info
{
"blockchain_head_block_num": 227738,
"blockchain_head_block_age": "5 seconds old",
"blockchain_head_block_timestamp": "2014-08-15T07:17:00",
"blockchain_average_delegate_participation": "91.82 %",
"blockchain_confirmation_requirement": 1,
"blockchain_accumulated_fees": "153,146.14196 BTSX",
"blockchain_delegate_pay_rate": "1.26608 BTSX",
"blockchain_share_supply": "1,999,957,225.95763 BTSX",
"blockchain_blocks_left_in_round": 17,
"blockchain_next_round_time": "3 minutes in the future",
"blockchain_next_round_timestamp": "2014-08-15T07:19:50",
"blockchain_random_seed": "14bfd263fd0987fa90ce853b16c3461e89f4524e",
"client_data_dir": "/home/emski/bitsharesnodeTock/bitsharesx/programs/client/dd4.0",
"network_num_connections": 66,
"network_num_connections_max": 200,
"ntp_time": "2014-08-15T07:17:05",
"ntp_time_error": -0.0043769999999999998,
"wallet_open": true,
"wallet_unlocked": true,
"wallet_unlocked_until": "37 minutes in the future",
"wallet_unlocked_until_timestamp": "2014-08-15T07:53:41",
"wallet_scan_progress": "? %",
"wallet_block_production_enabled": true,
"wallet_next_block_production_time": "at least 3 minutes in the future",
"wallet_next_block_production_timestamp": null
}
emski (unlocked) >>> blockchain_list_blocks
HEIGHT TIMESTAMP SIGNING DELEGATE # TXS SIZE TOTAL FEES LATENCY PROCESSING TIME
===================================================================================================================
227738 2014-08-15T07:17:00 dpos.crazybit 0 166 0.00000 BTSX 0 0.004883
227737 2014-08-15T07:16:50 fox 0 166 0.00000 BTSX 0 0.000117
MISSED 2014-08-15T07:16:40 lotto-delegate N/A N/A N/A N/A N/A
227736 2014-08-15T07:16:30 init34 0 166 0.00000 BTSX 0 0.002168
And where is my console.log ?
Output from 3.1 client:
227736
6b6301bb71de964c1a8f759f304316a3f6417967 lotto-delegate 2 502 2014-08-15T07:16:40 0 NO NO
71f889b8659ff455185586ebedca7e99a21a59bf fox 0 166 2014-08-15T07:16:50 0 YES YES
227744
704bd508f16573c486e8ba828026f257364cc340 delegate.webber 0 166 2014-08-15T07:18:10 0 YES NO
61d53df45eebe57e9f81632dc27eb845ced89d3e delegate.webber 0 166 2014-08-15T07:18:10 0 YES YES
REASONS FOR INVALID BLOCKS
6b6301bb71de964c1a8f759f304316a3f6417967: 10 assert_exception: Assert Exception
converter_itr != _converters.end():
{}
th_a operations.cpp:62 to_variant
{}
th_a operations.cpp:64 to_variant
{"trx_num":0}
th_a chain_database.cpp:1003 apply_transactions
-
What if the delegate in the round just after me hasn't updated?
When we are required to publish price feeds?
Should we do it for all currencies ?
-
Not sure if this is related to 0.4.0 delegates vs 0.3.1 but I'm see this. Note that I haven't missed a block because of this. I have not published a feed yet.
Peer 104.131.134.181:51145 disconnected us: You offered us a block that we reject as invalid
Peer 106.185.24.234:39314 disconnected us: You offered us a block that we reject as invalid
-
hm .. my backup system successfully upgraded and produced blocks .. when switching to the main system with 0.4.0 he missed blocks ... wlthough all seemed fine ..
strange .. looking into ito
//edit: seems I needed to reanble block production
-
A little confused as their are warnings not to upgrade and some download and build instructions have strikethroughs. Can you clarify please?
-
if you have a delegate running then you should update .. at the end everything is running fine .. at least at my end :)
-
if you have a delegate running then you should update .. at the end everything is running fine .. at least at my end :)
what about price feeds? Don't see any crystal clear instructions on that.
-
if you have a delegate running then you should update .. at the end everything is running fine .. at least at my end :)
what about price feeds? Don't see any crystal clear instructions on that.
I am on 0.4.0 without issue but have not touched price feeds yet.
-
if you have a delegate running then you should update .. at the end everything is running fine .. at least at my end :)
what about price feeds? Don't see any crystal clear instructions on that.
I am on 0.4.0 without issue but have not touched price feeds yet.
Okay, I'll do the upgrade but hold off on feeds.
-
running 0.4 and works fine for now, did't publish price feeds.
-
0.4.0 runs o.k. here on both machines. +5%
-
will upgrade but hold off feeds2 until clarifications will made ;)
-
I updated and everything seemed to work properly.
As soon as I published price feeds I started missing blocks.
emski (unlocked) >>> info
{
"blockchain_head_block_num": 227738,
"blockchain_head_block_age": "5 seconds old",
"blockchain_head_block_timestamp": "2014-08-15T07:17:00",
"blockchain_average_delegate_participation": "91.82 %",
"blockchain_confirmation_requirement": 1,
"blockchain_accumulated_fees": "153,146.14196 BTSX",
"blockchain_delegate_pay_rate": "1.26608 BTSX",
"blockchain_share_supply": "1,999,957,225.95763 BTSX",
"blockchain_blocks_left_in_round": 17,
"blockchain_next_round_time": "3 minutes in the future",
"blockchain_next_round_timestamp": "2014-08-15T07:19:50",
"blockchain_random_seed": "14bfd263fd0987fa90ce853b16c3461e89f4524e",
"client_data_dir": "/home/emski/bitsharesnodeTock/bitsharesx/programs/client/dd4.0",
"network_num_connections": 66,
"network_num_connections_max": 200,
"ntp_time": "2014-08-15T07:17:05",
"ntp_time_error": -0.0043769999999999998,
"wallet_open": true,
"wallet_unlocked": true,
"wallet_unlocked_until": "37 minutes in the future",
"wallet_unlocked_until_timestamp": "2014-08-15T07:53:41",
"wallet_scan_progress": "? %",
"wallet_block_production_enabled": true,
"wallet_next_block_production_time": "at least 3 minutes in the future",
"wallet_next_block_production_timestamp": null
}
emski (unlocked) >>> blockchain_list_blocks
HEIGHT TIMESTAMP SIGNING DELEGATE # TXS SIZE TOTAL FEES LATENCY PROCESSING TIME
===================================================================================================================
227738 2014-08-15T07:17:00 dpos.crazybit 0 166 0.00000 BTSX 0 0.004883
227737 2014-08-15T07:16:50 fox 0 166 0.00000 BTSX 0 0.000117
MISSED 2014-08-15T07:16:40 lotto-delegate N/A N/A N/A N/A N/A
227736 2014-08-15T07:16:30 init34 0 166 0.00000 BTSX 0 0.002168
And where is my console.log ?
Output from 3.1 client:
227736
6b6301bb71de964c1a8f759f304316a3f6417967 lotto-delegate 2 502 2014-08-15T07:16:40 0 NO NO
71f889b8659ff455185586ebedca7e99a21a59bf fox 0 166 2014-08-15T07:16:50 0 YES YES
227744
704bd508f16573c486e8ba828026f257364cc340 delegate.webber 0 166 2014-08-15T07:18:10 0 YES NO
61d53df45eebe57e9f81632dc27eb845ced89d3e delegate.webber 0 166 2014-08-15T07:18:10 0 YES YES
REASONS FOR INVALID BLOCKS
6b6301bb71de964c1a8f759f304316a3f6417967: 10 assert_exception: Assert Exception
converter_itr != _converters.end():
{}
th_a operations.cpp:62 to_variant
{}
th_a operations.cpp:64 to_variant
{"trx_num":0}
th_a chain_database.cpp:1003 apply_transactions
What if the delegate in the round just after me hasn't updated?
When we are required to publish price feeds?
Should we do it for all currencies ?
Not sure if this is related to 0.4.0 delegates vs 0.3.1 but I'm see this. Note that I haven't missed a block because of this. I have not published a feed yet.
Peer 104.131.134.181:51145 disconnected us: You offered us a block that we reject as invalid
Peer 106.185.24.234:39314 disconnected us: You offered us a block that we reject as invalid
hm .. my backup system successfully upgraded and produced blocks .. when switching to the main system with 0.4.0 he missed blocks ... wlthough all seemed fine ..
strange .. looking into ito
//edit: seems I needed to reanble block production
Do not publish price feeds until after hardfork and all clients are upgraded. This is a new operation that is part of the hardfork. All old clients will reject blocks containing publish price feed operation. This is the reason for missed blocks.
Large transaction and block sizes are also part of the hardfork, and could result in missed blocks.
console.log was disabled by default in previous update for security concerns. It can be enabled using --log-commands argument.
Delegates are still free to upgrade but must be aware that there a crashing issue has been identified. Brave delegates can upgrade and run client in a debugger to help us get a stack trace of the crash.
-
No one should publish feeds until we have a chance to provide some more guidance.
I updated and everything seemed to work properly.
As soon as I published price feeds I started missing blocks.
emski (unlocked) >>> info
{
"blockchain_head_block_num": 227738,
"blockchain_head_block_age": "5 seconds old",
"blockchain_head_block_timestamp": "2014-08-15T07:17:00",
"blockchain_average_delegate_participation": "91.82 %",
"blockchain_confirmation_requirement": 1,
"blockchain_accumulated_fees": "153,146.14196 BTSX",
"blockchain_delegate_pay_rate": "1.26608 BTSX",
"blockchain_share_supply": "1,999,957,225.95763 BTSX",
"blockchain_blocks_left_in_round": 17,
"blockchain_next_round_time": "3 minutes in the future",
"blockchain_next_round_timestamp": "2014-08-15T07:19:50",
"blockchain_random_seed": "14bfd263fd0987fa90ce853b16c3461e89f4524e",
"client_data_dir": "/home/emski/bitsharesnodeTock/bitsharesx/programs/client/dd4.0",
"network_num_connections": 66,
"network_num_connections_max": 200,
"ntp_time": "2014-08-15T07:17:05",
"ntp_time_error": -0.0043769999999999998,
"wallet_open": true,
"wallet_unlocked": true,
"wallet_unlocked_until": "37 minutes in the future",
"wallet_unlocked_until_timestamp": "2014-08-15T07:53:41",
"wallet_scan_progress": "? %",
"wallet_block_production_enabled": true,
"wallet_next_block_production_time": "at least 3 minutes in the future",
"wallet_next_block_production_timestamp": null
}
emski (unlocked) >>> blockchain_list_blocks
HEIGHT TIMESTAMP SIGNING DELEGATE # TXS SIZE TOTAL FEES LATENCY PROCESSING TIME
===================================================================================================================
227738 2014-08-15T07:17:00 dpos.crazybit 0 166 0.00000 BTSX 0 0.004883
227737 2014-08-15T07:16:50 fox 0 166 0.00000 BTSX 0 0.000117
MISSED 2014-08-15T07:16:40 lotto-delegate N/A N/A N/A N/A N/A
227736 2014-08-15T07:16:30 init34 0 166 0.00000 BTSX 0 0.002168
And where is my console.log ?
Output from 3.1 client:
227736
6b6301bb71de964c1a8f759f304316a3f6417967 lotto-delegate 2 502 2014-08-15T07:16:40 0 NO NO
71f889b8659ff455185586ebedca7e99a21a59bf fox 0 166 2014-08-15T07:16:50 0 YES YES
227744
704bd508f16573c486e8ba828026f257364cc340 delegate.webber 0 166 2014-08-15T07:18:10 0 YES NO
61d53df45eebe57e9f81632dc27eb845ced89d3e delegate.webber 0 166 2014-08-15T07:18:10 0 YES YES
REASONS FOR INVALID BLOCKS
6b6301bb71de964c1a8f759f304316a3f6417967: 10 assert_exception: Assert Exception
converter_itr != _converters.end():
{}
th_a operations.cpp:62 to_variant
{}
th_a operations.cpp:64 to_variant
{"trx_num":0}
th_a chain_database.cpp:1003 apply_transactions
What if the delegate in the round just after me hasn't updated?
When we are required to publish price feeds?
Should we do it for all currencies ?
Not sure if this is related to 0.4.0 delegates vs 0.3.1 but I'm see this. Note that I haven't missed a block because of this. I have not published a feed yet.
Peer 104.131.134.181:51145 disconnected us: You offered us a block that we reject as invalid
Peer 106.185.24.234:39314 disconnected us: You offered us a block that we reject as invalid
hm .. my backup system successfully upgraded and produced blocks .. when switching to the main system with 0.4.0 he missed blocks ... wlthough all seemed fine ..
strange .. looking into ito
//edit: seems I needed to reanble block production
Do not publish price feeds until after hardfork and all clients are upgraded. This is a new operation that is part of the hardfork. All old clients will reject blocks containing publish price feed operation. This is the reason for missed blocks.
Large transaction and block sizes are also part of the hardfork, and could result in missed blocks.
console.log was disabled by default in previous update for security concerns. It can be enabled using --log-commands argument.
Delegates are still free to upgrade but must be aware that there a crashing issue has been identified. Brave delegates can upgrade and run client in a debugger to help us get a stack trace of the crash.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
I updated and everything seemed to work properly.
As soon as I published price feeds I started missing blocks.
emski (unlocked) >>> info
{
"blockchain_head_block_num": 227738,
"blockchain_head_block_age": "5 seconds old",
"blockchain_head_block_timestamp": "2014-08-15T07:17:00",
"blockchain_average_delegate_participation": "91.82 %",
"blockchain_confirmation_requirement": 1,
"blockchain_accumulated_fees": "153,146.14196 BTSX",
"blockchain_delegate_pay_rate": "1.26608 BTSX",
"blockchain_share_supply": "1,999,957,225.95763 BTSX",
"blockchain_blocks_left_in_round": 17,
"blockchain_next_round_time": "3 minutes in the future",
"blockchain_next_round_timestamp": "2014-08-15T07:19:50",
"blockchain_random_seed": "14bfd263fd0987fa90ce853b16c3461e89f4524e",
"client_data_dir": "/home/emski/bitsharesnodeTock/bitsharesx/programs/client/dd4.0",
"network_num_connections": 66,
"network_num_connections_max": 200,
"ntp_time": "2014-08-15T07:17:05",
"ntp_time_error": -0.0043769999999999998,
"wallet_open": true,
"wallet_unlocked": true,
"wallet_unlocked_until": "37 minutes in the future",
"wallet_unlocked_until_timestamp": "2014-08-15T07:53:41",
"wallet_scan_progress": "? %",
"wallet_block_production_enabled": true,
"wallet_next_block_production_time": "at least 3 minutes in the future",
"wallet_next_block_production_timestamp": null
}
emski (unlocked) >>> blockchain_list_blocks
HEIGHT TIMESTAMP SIGNING DELEGATE # TXS SIZE TOTAL FEES LATENCY PROCESSING TIME
===================================================================================================================
227738 2014-08-15T07:17:00 dpos.crazybit 0 166 0.00000 BTSX 0 0.004883
227737 2014-08-15T07:16:50 fox 0 166 0.00000 BTSX 0 0.000117
MISSED 2014-08-15T07:16:40 lotto-delegate N/A N/A N/A N/A N/A
227736 2014-08-15T07:16:30 init34 0 166 0.00000 BTSX 0 0.002168
And where is my console.log ?
Output from 3.1 client:
227736
6b6301bb71de964c1a8f759f304316a3f6417967 lotto-delegate 2 502 2014-08-15T07:16:40 0 NO NO
71f889b8659ff455185586ebedca7e99a21a59bf fox 0 166 2014-08-15T07:16:50 0 YES YES
227744
704bd508f16573c486e8ba828026f257364cc340 delegate.webber 0 166 2014-08-15T07:18:10 0 YES NO
61d53df45eebe57e9f81632dc27eb845ced89d3e delegate.webber 0 166 2014-08-15T07:18:10 0 YES YES
REASONS FOR INVALID BLOCKS
6b6301bb71de964c1a8f759f304316a3f6417967: 10 assert_exception: Assert Exception
converter_itr != _converters.end():
{}
th_a operations.cpp:62 to_variant
{}
th_a operations.cpp:64 to_variant
{"trx_num":0}
th_a chain_database.cpp:1003 apply_transactions
What if the delegate in the round just after me hasn't updated?
When we are required to publish price feeds?
Should we do it for all currencies ?
Not sure if this is related to 0.4.0 delegates vs 0.3.1 but I'm see this. Note that I haven't missed a block because of this. I have not published a feed yet.
Peer 104.131.134.181:51145 disconnected us: You offered us a block that we reject as invalid
Peer 106.185.24.234:39314 disconnected us: You offered us a block that we reject as invalid
hm .. my backup system successfully upgraded and produced blocks .. when switching to the main system with 0.4.0 he missed blocks ... wlthough all seemed fine ..
strange .. looking into ito
//edit: seems I needed to reanble block production
Do not publish price feeds until after hardfork and all clients are upgraded. This is a new operation that is part of the hardfork. All old clients will reject blocks containing publish price feed operation. This is the reason for missed blocks.
Large transaction and block sizes are also part of the hardfork, and could result in missed blocks.
console.log was disabled by default in previous update for security concerns. It can be enabled using --log-commands argument.
Delegates are still free to upgrade but must be aware that there a crashing issue has been identified. Brave delegates can upgrade and run client in a debugger to help us get a stack trace of the crash.
ah, great.
The Unwittingly Brave
-
Is the crashing only related to price feeds?
-
Is the crashing only related to price feeds?
Unknown, we are still trying to track it down.
-
So..... 0.4.1..... crash fixed?
-
So..... 0.4.1..... crash fixed?
not confirmed yet, some brave delegates are running in gdb trying to catch it.
-
just upgrating to 0.4.1 .. lets check that out ..
0.4.0 was working fine for me though
-
0.4.1 running without issue.
-
Is the crash issue rearing its ugly head outside of delegate operations? Would upgrading my webwallet and public node and running under gdb help?
-
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.
-
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?
-
No crashes except some missed blocks on 0.4.0 for more than 12 hours.
-
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.
-
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....
(http://1.bp.blogspot.com/-ZOm7F6DredU/U-9ESc1NY4I/AAAAAAAADEo/zAeOmZo3XOc/s1600/cli1.png)
EDIT:
it happens often to see now:
"wallet_next_block_production_timestamp": null
(http://4.bp.blogspot.com/-oZXNBKWJq9I/U-9FuLR4ndI/AAAAAAAADE0/nD1S7MAkF84/s1600/cli2.png)
-
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....
(http://1.bp.blogspot.com/-ZOm7F6DredU/U-9ESc1NY4I/AAAAAAAADEo/zAeOmZo3XOc/s1600/cli1.png)
EDIT:
it happens often to see now:
"wallet_next_block_production_timestamp": null
(http://4.bp.blogspot.com/-oZXNBKWJq9I/U-9FuLR4ndI/AAAAAAAADE0/nD1S7MAkF84/s1600/cli2.png)
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
-
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 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".....
-
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.
-
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?
-
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
-
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.
-
0.4.2 is coming soon, all delegates need to update it.
https://bitsharestalk.org/index.php?topic=7067.0