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.

[xeroc]

just upgrating to 0.4.1 .. lets check that out ..
0.4.0 was working fine for me though

[HackFisher]

So..... 0.4.1..... crash fixed?

not confirmed yet, some brave delegates are running in gdb trying to catch it.

[bdnoble]

So..... 0.4.1..... crash fixed?

[vikram]

Is the crashing only related to price feeds?

Unknown, we are still trying to track it down.

[GaltReport]

Is the crashing only related to price feeds?

[GaltReport]

I updated and everything seemed to work properly.
As soon as I published price feeds I started missing blocks.

Code Select Expand

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 Expand

     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 Expand



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

[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 Expand

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 Expand

     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 Expand



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

[vikram]

I updated and everything seemed to work properly.
As soon as I published price feeds I started missing blocks.

Code Select Expand

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 Expand

     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 Expand



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.

[liondani]

will upgrade but hold off feeds2 until clarifications will made  ;)

[CalabiYau]

0.4.0 runs o.k. here on both machines.  +5%

[cgafeng]

running 0.4 and works fine for now, did't publish price feeds.

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

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

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

[xeroc]

if you have a delegate running then you should update .. at the end everything is running fine .. at least at my end :)

[GaltReport]

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

[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

[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 Expand



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


[emski]

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 ?

[emski]

I updated and everything seemed to work properly.
As soon as I published price feeds I started missing blocks.

Code Select Expand

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 Expand

     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


[xeroc]

one can count the hours to release now :) exciting

[alt]

market function is active???  :'(

[Ggozzo]

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.

[toast]

- Market has been overhauled and market-pegged BitAssets have been added

O=

=O

||
O

[DACSunlimited]

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