Author Topic: Delegates and seed nodes, upgrade your client version to 0.4.1  (Read 7817 times)

0 Members and 1 Guest are viewing this topic.

Offline DACSunlimited

  • Full Member
  • ***
  • Posts: 136
    • View Profile

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
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.
« Last Edit: August 18, 2014, 11:28:09 pm by emski »

Offline 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
« Last Edit: August 18, 2014, 11:08:55 pm by vikram »

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: 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?

Offline bdnoble

  • Full Member
  • ***
  • Posts: 116
    • View Profile
    • Home Page
Quote
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.
:)

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
Quote
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".....
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bytemaster

Quote
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. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
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
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: 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


« Last Edit: August 16, 2014, 11:53:45 am by liondani »

Offline puppies

  • Hero Member
  • *****
  • Posts: 1659
    • View Profile
  • BitShares: 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.   
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
No crashes except some missed blocks on 0.4.0 for more than 12 hours.

Offline 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?


Offline 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.

Offline puppies

  • Hero Member
  • *****
  • Posts: 1659
    • View Profile
  • BitShares: 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?
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Riverhead


Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
just upgrating to 0.4.1 .. lets check that out ..
0.4.0 was working fine for me though

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
So..... 0.4.1..... crash fixed?

not confirmed yet, some brave delegates are running in gdb trying to catch it.
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bdnoble

  • Full Member
  • ***
  • Posts: 116
    • View Profile
    • Home Page
:)

Offline vikram

Is the crashing only related to price feeds?

Unknown, we are still trying to track it down.

Offline GaltReport


Offline GaltReport

I updated and everything seemed to work properly.
As soon as I published price feeds I started missing blocks.
Code: [Select]
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:
Code: [Select]
     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.


Code: [Select]

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


Offline bytemaster

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.
Code: [Select]
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:
Code: [Select]
     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.


Code: [Select]

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
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline vikram

I updated and everything seemed to work properly.
As soon as I published price feeds I started missing blocks.
Code: [Select]
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:
Code: [Select]
     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.


Code: [Select]

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.

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
will upgrade but hold off feeds2 until clarifications will made  ;)

Offline CalabiYau


Offline cgafeng

running 0.4 and works fine for now, did't publish price feeds.
BTC:1EYwcZ9cYVj6C9LMLafdcjK9wicVMDV376

Offline GaltReport

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.

Offline Riverhead

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.

Offline GaltReport

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.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
if you have a delegate running then you should update .. at the end everything is running fine .. at least at my end :)

Offline GaltReport

A little confused as their are warnings not to upgrade and some download and build instructions have strikethroughs.  Can you clarify please?

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
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
« Last Edit: August 15, 2014, 09:14:32 am by xeroc »

Offline Riverhead

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.


Code: [Select]

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

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
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 ?

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
I updated and everything seemed to work properly.
As soon as I published price feeds I started missing blocks.
Code: [Select]
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:
Code: [Select]
     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
« Last Edit: August 15, 2014, 07:22:49 am by emski »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
one can count the hours to release now :) exciting

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi

Ggozzo

  • Guest
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.

Offline toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
Quote
- Market has been overhauled and market-pegged BitAssets have been added

O=

=O

||
O
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline DACSunlimited

  • Full Member
  • ***
  • Posts: 136
    • View Profile
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:
Quote
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
« Last Edit: August 16, 2014, 02:43:20 pm by DACSunlimited »