--> All Delegates: Please upgrade to 0.4.27.1 ASAP <--

[iHashFury]

Delegate updated to v0.4.27.1

I had some issues with sending funds to publish feeds but all is well again

[Riverhead]

Isn't the multiple chains block signing a security issue ?
How can one be sure that his client is on the right chain with 60% delegate participation if 40% of these delegates sign in two chains ?

That is a delegate issue based upon their use of their custom software.  It should be a fireable offense to produce on more than one chain.

Currently we need to develop all our support scripts in production environments. DevShares will be a nice change of stress.

.
Why don't you just try to theoretically explain the delegate backup system first?

Sorry Emski, I didn't see this question until now. What happened with my delegate wasn't an automated backup system. Currently I have no scripts in place that detect one node missing blocks to enable another. I have ideas about that but have been too afraid of signing on two chains (ya, I know ). What happened the other night was a setup designed to survive a reboot kicked in when the instance rebooted. The scripts didn't have a check to see if the node was active before reboot. I have since moved the wallet directory to wallet.standby so that the node can still stay in sync without risk of it becoming unlocked.

It was a stupid oversight and I've paid for it; both literally and figuratively.

[emski]

Isn't the multiple chains block signing a security issue ?
How can one be sure that his client is on the right chain with 60% delegate participation if 40% of these delegates sign in two chains ?

That is a delegate issue based upon their use of their custom software.  It should be a fireable offense to produce on more than one chain.

Currently we need to develop all our support scripts in production environments. DevShares will be a nice change of stress.

Why don't you just try to theoretically explain the delegate backup system first?

[Riverhead]

Isn't the multiple chains block signing a security issue ?
How can one be sure that his client is on the right chain with 60% delegate participation if 40% of these delegates sign in two chains ?

That is a delegate issue based upon their use of their custom software.  It should be a fireable offense to produce on more than one chain.

Currently we need to develop all our support scripts in production environments. DevShares will be a nice change of stress.

[alt]

I have update to 0.4.27.1, but offen stop sync. here is some information
stop at block 1288364

Code: [Select]

  "blockchain_head_block_num": 1288364,
  "blockchain_head_block_age": "12 minutes old",
  "blockchain_head_block_timestamp": "2014-12-18T01:54:20",
  "blockchain_average_delegate_participation": "52.33 %",
there is a fork at here

Code: [Select]

        1288363
     1e52304898b7e133a3c5f70e28fc2e98642d98b4           bitsharesx-delegate              4      4042 2014-12-18T01:54:20         0     YES                  NO
     44bd8acf6b7d9f6a11158c8a87652b1e2a29f739                   black-widow              3      3798 2014-12-18T01:54:30         0     N/A                  NO

and from the log file, it can't find block 1288364 at database

Code: [Select]

2014-12-18T01:54:40 th_a:invoke handle_message       switch_to_fork ]     pop 1e52304898b7e133a3c5f70e28fc2e98642d98b4      chain_database.cpp:693
2014-12-18T01:54:40 th_a:invoke handle_message           push_block ] fork permanently rejected as it has permanently invalid block     chain_database.cpp:1745
2014-12-18T01:54:40 p2p:message read_loop process_block_during ] Successfully pushed block 1288365 (id:75bda8624c5b6d389683a549701cccd55762ea2a)      node.cpp:3050
2014-12-18T01:54:41 p2p:message read_loop            read_loop ] message transmission failed 6 key_not_found_exception: Key Not Found
unable to find key 1288364
    {"key":1288364}
    th_a  level_map.hpp:102 fetch
error fetching key 1288364
    {"key":1288364}
    th_a  level_map.hpp:112 fetch

    {"block_num":1288364}
    th_a  chain_database.cpp:1647 get_block     message_oriented_connection.cpp:165
2014-12-18T01:54:41 p2p:message read_loop            read_loop ] disconnected 6 key_not_found_exception: Key Not Found

I have to restart client, then it can sync again.

[emski]

Isn't the multiple chains block signing a security issue ?
How can one be sure that his client is on the right chain with 60% delegate participation if 40% of these delegates sign in two chains ?

That is a delegate issue based upon their use of their custom software.  It should be a fireable offense to produce on more than one chain.

This was discussed several times before.
Can this be made sticky and/or explicitly stated in a new thread.

[bytemaster]

Isn't the multiple chains block signing a security issue ?
How can one be sure that his client is on the right chain with 60% delegate participation if 40% of these delegates sign in two chains ?

That is a delegate issue based upon their use of their custom software.  It should be a fireable offense to produce on more than one chain. 

[clayop]

FYI, for anyone running a windows delegate (yes, there are some out there), I've added a Windows installer for 0.4.27.1 here:
https://github.com/BitShares/bitshares/releases/tag/v0.4.27.1

Thanks. Reindexing now, and my standby delegate has been updated.

[dannotestein]

FYI, for anyone running a windows delegate (yes, there are some out there), I've added a Windows installer for 0.4.27.1 here:
https://github.com/BitShares/bitshares/releases/tag/v0.4.27.1

[emski]

Isn't the multiple chains block signing a security issue ?
How can one be sure that his client is on the right chain with 60% delegate participation if 40% of these delegates sign in two chains ?

[cube]

Updated to v0.4.27.  I am fortunate not to have chain issue.

[dannotestein]

@maqifrnswa, Try https://github.com/BitShares/bitshares/releases/tag/v0.4.27.1

[maqifrnswa]

I deleted my chain and peer dbs, then redownloaded the chain on 0.4.27:

Machine 1 (0.4.27):

Code: [Select]

--- in sync with p2p network
(wallet closed) >>> info
{
  "blockchain_head_block_num": 1283018,
  "blockchain_head_block_age": "13 hours old",
  "blockchain_head_block_timestamp": "2014-12-17T06:27:10",
  "blockchain_average_delegate_participation": "2.18 %",
  "blockchain_confirmation_requirement": 1,
  "blockchain_share_supply": "2,498,420,479.09030 BTS",
  "blockchain_blocks_left_in_round": 86,
  "blockchain_next_round_time": "at least 14 minutes in the future",
  "blockchain_next_round_timestamp": "2014-12-17T19:14:50",
  "blockchain_random_seed": "9c8436243078d56f4ca9216c8233a7758d084452",
  "client_data_dir": "/home/showard/.BitShares",
  "client_version": "v0.4.27",
  "network_num_connections": 8,
  "network_num_connections_max": 200,
  "network_chain_downloader_running": false,
  "network_chain_downloader_blocks_remaining": null,
  "ntp_time": "2014-12-17T19:00:32",
  "ntp_time_error": 0.0020690000000000001,
  "wallet_open": false,
  "wallet_unlocked": null,
  "wallet_unlocked_until": null,
  "wallet_unlocked_until_timestamp": null,
  "wallet_last_scanned_block_timestamp": null,
  "wallet_scan_progress": null,
  "wallet_block_production_enabled": null,
  "wallet_next_block_production_time": null,
  "wallet_next_block_production_timestamp": null

(wallet closed) >> blockchain_list_forks
   FORKED BLOCK              FORKING BLOCK ID              SIGNING DELEGATE      TXN COUNT      SIZE           TIMESTAMP   LATENCY   VALID    IN CURRENT CHAIN
--------------------------------------------------------------------------------------------------------------------------------------------------------------
        1283018
     11afe1649155b854b5bb3c69021a39151df5ef12          bm.payroll.riverhead              4      1572 2014-12-17T06:27:20     45172      NO                  NO
     ec9e8670a9099bb830fe1275298ca03b1b10c555                         emski              2       998 2014-12-17T06:27:40     45153      NO                  NO
REASONS FOR INVALID BLOCKS
11afe1649155b854b5bb3c69021a39151df5ef12: 30007 duplicate_transaction: duplicate transaction

    {"trx_id":"0b37cd2a4dc1c10ae1ecb7bb44b0af30aaf778b6"}
    th_a  transaction_evaluation_state.cpp:212 evaluate

    {"trx":{"expiration":"2014-12-17T07:34:30","delegate_slate_id":null,"operations":[{"type":"update_feed_op_type","data":{"feed":{"feed_id":4,"delegate_id":14872},"value":{"ratio":"0.045095236539076448","quote_asset_id":4,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":14,"delegate_id":14872},"value":{"ratio":"0.00922438485977705","quote_asset_id":14,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":7,"delegate_id":14872},"value":{"ratio":"0.000124300399590475","quote_asset_id":7,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":22,"delegate_id":14872},"value":{"ratio":"0.001489678120825724","quote_asset_id":22,"base_asset_id":0}}},{"type":"withdraw_pay_op_type","data":{"amount":50000,"account_id":14872}}],"signatures":["1f3b48e355cd4086284045565a299fe46e514cdbe69e2b2147b5f16ea3f22fa8ab4832a7bd4d28527f202a0a8fcb47578d8deaeb8bf769955b0bdcd4a504d07214"]}}
    th_a  transaction_evaluation_state.cpp:244 evaluate

    {"trx_num":0}
    th_a  chain_database.cpp:729 apply_transactions
ec9e8670a9099bb830fe1275298ca03b1b10c555: 30007 duplicate_transaction: duplicate transaction

    {"trx_id":"9273cbde64d4edde9103776c723cf59665af4f71"}
    th_a  transaction_evaluation_state.cpp:212 evaluate

    {"trx":{"expiration":"2014-12-17T07:34:43","delegate_slate_id":null,"operations":[{"type":"update_feed_op_type","data":{"feed":{"feed_id":4,"delegate_id":18766},"value":{"ratio":"0.045084141539375624","quote_asset_id":4,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":14,"delegate_id":18766},"value":{"ratio":"0.00922686315058886","quote_asset_id":14,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":7,"delegate_id":18766},"value":{"ratio":"0.000124323783549378","quote_asset_id":7,"base_asset_id":0}}},{"type":"update_feed_op_type","data":{"feed":{"feed_id":22,"delegate_id":18766},"value":{"ratio":"0.001490020525769598","quote_asset_id":22,"base_asset_id":0}}},{"type":"withdraw_pay_op_type","data":{"amount":50000,"account_id":18766}}],"signatures":["1f6616c9788206f632eae3154714ca09fcf367c8511cd56129f530449f674ac86022bb4cd0b4993fda63b4420f21d7a714626bb7b31f91ba8bbb3196a9ae0b18b6"]}}
    th_a  transaction_evaluation_state.cpp:244 evaluate

    {"trx_num":0}
    th_a  chain_database.cpp:729 apply_transactions

}
but it seems to still be on the fork (compared to another machine)

Machine 2 (0.4.26):

Code: [Select]

default (unlocked) >>> info
{
  "blockchain_head_block_num": 1286385,
  "blockchain_head_block_age": "1 second old",
  "blockchain_head_block_timestamp": "2014-12-17T19:03:40",
  "blockchain_average_delegate_participation": "72.66 %",
  "blockchain_confirmation_requirement": 7,
  "blockchain_share_supply": "2,498,439,830.19030 BTS",
  "blockchain_blocks_left_in_round": 52,
  "blockchain_next_round_time": "at least 9 minutes in the future",
  "blockchain_next_round_timestamp": "2014-12-17T19:12:20",
  "blockchain_random_seed": "6e6343e36995b304269ba0bf45dfb9078c36c098",
  "client_data_dir": "/home/showard/.BitShares",
  "client_version": "v0.4.26",
  "network_num_connections": 10,
  "network_num_connections_max": 10,
  "network_chain_downloader_running": false,
  "network_chain_downloader_blocks_remaining": null,
  "ntp_time": "2014-12-17T19:03:41",
  "ntp_time_error": 0.00090200000000000002,
  "wallet_open": true,
  "wallet_unlocked": true,
  "wallet_unlocked_until": "3 years 2 months in the future",
  "wallet_unlocked_until_timestamp": "2018-02-13T03:46:55",
  "wallet_last_scanned_block_timestamp": "2014-11-12T00:42:40",
  "wallet_scan_progress": "? %",
  "wallet_block_production_enabled": true,
  "wallet_next_block_production_time": "49 seconds in the future",
  "wallet_next_block_production_timestamp": "2014-12-17T19:04:30"


[bytemaster]

When will we have a stable client where there will not be an update every 24 hours? I may just wait to update my personal wallet until 1.0 is released.

Light weight wallet will not require updates.   One month or so. 

[islandking]

When will we have a stable client where there will not be an update every 24 hours? I may just wait to update my personal wallet until 1.0 is released.

[bytemaster]

I have a working fix in place.  There is no security issue.

The issue involves false positives on duplicate transactions when switching from a "short fork" to the "long fork" because our cache of "known transaction ids" wasn't properly cleared when unwinding the short fork.  When attempting to apply the longer fork it failed due to "duplicate transaction".   This means that what use to be a "small issue" of a single missed block could turn into a "large issue" of delegates going down two different paths. 

We also have the issue that some delegates have automatic backup nodes that prevent them from missing blocks.  These backup nodes would activate after they went down a different fork than the master and thus both forks add a cumulative participation greater than 100%.   As a result we produced a few very long (longer than 404 blocks) minority forks.   These long minority forks exceeded the undo history which meant that once your client went down that minority fork it was a dead end with no turning back except to attempt a fresh download of the entire chain.

We have put in a fix for the false positive issue and increased the undo history to 1616 blocks.  Delegates should upgrade to help reduce forking.  This is not a required upgrade for end users, but it will help them get on the right fork.   

[theoreticalbts]

Sounds juicy!

In this case, it's more of an abundance of caution.  I personally don't think this bug is exploitable (or at any rate that exploitation will be able to do anything worse than what's already happening naturally).  But we're still waiting until the fix is released to discuss details.

[monsterer]

We think we understand what has been causing the network to fork repeatedly over the past 12 hours or so.  We're currently working on implementing a fix.  We prefer not to publicly explain what's going on until the fix is released.

Sounds juicy!

[theoreticalbts]

We think we understand what has been causing the network to fork repeatedly over the past 12 hours or so.  We're currently working on implementing a fix.  We prefer not to publicly explain what's going on until the fix is released.

[Riverhead]

Even though these delegates were informed about the dangers of multiple chain block signing
and about the flaws of current public automated delegate backup system implementations they still used it.

I agree. However multiple chain block signing is a real risk now that version updates are longer than round times. In my case today the double signing was due to efforts to have the delegate survive a full machine crash and/or reboot by the vendor. Sadly it worked =/. I have it disabled on the backup VPS and only enabled on the live VPS.

To further prevent this from happening again I have moved the wallets directory out of the data-dir so even if it comes online it won't try to sign blocks.

[emski]

Even though these delegates were informed about the dangers of multiple chain block signing
and about the flaws of current public automated delegate backup system implementations they still used it.

Perhaps this should be made a bit more clear.

Anyway it looks like everyone is working to resolve the issues and there is no harm done.

[cube]

Aren't they supposed to be fired for this? Lol

The developers that introduced the forking code to make the network more robust or the delegates who are quickly adapting to keep the network running while the kinks are worked out?

Who would you have replace them that you think would do a better job?

Everyone is doing their best to get it working.  There is no need to fire anyone.

[Riverhead]

Aren't they supposed to be fired for this? Lol

The developers that introduced the forking code to make the network more robust or the delegates who are quickly adapting to keep the network running while the kinks are worked out?

Who would you have replace them that you think would do a better job?

[NewMine]

1283481 2014-12-17T11:33:40 backbone.riverhead              0       166     544     0.002572         d310b14962c87e4a97600e6f6b6d0d72e6039cad
you are signing the wrong chain
[13:49:25] Emil Velichkov: crazibyt, chinesecommunity, bm.payroll.riverhead, rose.ebit, titan.crazybit
[13:49:59] Emil Velichkov: including x.ebit
[13:50:00] Emil Velichkov: fox
[13:50:15] Emil Velichkov: *.helloworld
[13:50:23] Emil Velichkov: del0.cass
[13:50:29] Emil Velichkov: marketing.methodx
[13:50:59] Emil Velichkov: riverhead-del-server-1
[13:51:30] Emil Velichkov: anchor.crazybit
[13:52:00] Emil Velichkov: dc-delegate
[13:52:20] Emil Velichkov: there are still seed nodes on the forked chain and some delegates actively producing blocks there
[13:53:04] Emil Velichkov: if someone can reach out the the above-mentioned delegates that would be cool

Aren't they supposed to be fired for this? Lol

[Riverhead]

I had a backup server come online after a restart. The situation has been corrected and updated to not repeat.

[ebit]

Thanks,I will try

[liondani]

if you delete "chain" folder this message will not show again  if I am right


PS make a restart and try again before you take my advice (maybe you save the resync time)

[ebit]

when run :  ./bitshares_client

------------ error --------------
10 assert_exception: Assert Exception
_map->is_open(): Database is not open!
    {}
    th_a  level_map.hpp:305 commit
error applying batch
    {}
    th_a  level_map.hpp:314 commit

    {}
    th_a  cached_level_map.hpp:52 flush

    {}
    th_a  cached_level_map.hpp:28 close

    {}
    th_a  chain_database.cpp:1485 close

    {"data_dir":"/root/.BitShares/chain"}
    th_a  chain_database.cpp:1434 open

    {"data_dir":"/root/.BitShares"}
    th_a  client.cpp:1365 open

[CalabiYau]

[13:44:18] Emil Velichkov: so checkpoints and --resync-blockchain does NOT work

Confirmed !

[emski]

1283481 2014-12-17T11:33:40 backbone.riverhead              0       166     544     0.002572         d310b14962c87e4a97600e6f6b6d0d72e6039cad
you are signing the wrong chain
[13:49:25] Emil Velichkov: crazibyt, chinesecommunity, bm.payroll.riverhead, rose.ebit, titan.crazybit
[13:49:59] Emil Velichkov: including x.ebit
[13:50:00] Emil Velichkov: fox
[13:50:15] Emil Velichkov: *.helloworld
[13:50:23] Emil Velichkov: del0.cass
[13:50:29] Emil Velichkov: marketing.methodx
[13:50:59] Emil Velichkov: riverhead-del-server-1
[13:51:30] Emil Velichkov: anchor.crazybit
[13:52:00] Emil Velichkov: dc-delegate
[13:52:20] Emil Velichkov: there are still seed nodes on the forked chain and some delegates actively producing blocks there
[13:53:04] Emil Velichkov: if someone can reach out the the above-mentioned delegates that would be cool

[emski]

Here is the output of my delegate after update to 0.4.27 and --resync-blockchain (and I've deleted everything in data-dir except wallet):

Code: [Select]

I am disconnecting peer 84.238.140.192:42577 for reason: You offered us a block that we reject as invalid
(wallet closed) >>> info
{
  "blockchain_head_block_num": 1283490,
  "blockchain_head_block_age": "2 minutes old",
  "blockchain_head_block_timestamp": "2014-12-17T11:40:40",
  "blockchain_average_delegate_participation": "17.18 %",
  "blockchain_confirmation_requirement": 303,
  "blockchain_share_supply": "2,498,424,296.59030 BTS",
  "blockchain_blocks_left_in_round": 18,
  "blockchain_next_round_time": "at least 3 minutes in the future",
  "blockchain_next_round_timestamp": "2014-12-17T11:45:50",
  "blockchain_random_seed": "9fd5828f7cc87cbf48c62745c4a6181510072306",
  "client_data_dir": "/home/emski/bitsharesAltDelegate/bitshares/programs/client/dd",
  "client_version": "v0.4.27",
  "network_num_connections": 9,
  "network_num_connections_max": 200,
  "network_chain_downloader_running": false,
  "network_chain_downloader_blocks_remaining": null,
  "ntp_time": "2014-12-17T11:42:50",
  "ntp_time_error": 0.0055840000000000004,
  "wallet_open": false,
  "wallet_unlocked": null,
  "wallet_unlocked_until": null,
  "wallet_unlocked_until_timestamp": null,
  "wallet_last_scanned_block_timestamp": null,
  "wallet_scan_progress": null,
  "wallet_block_production_enabled": null,
  "wallet_next_block_production_time": null,
  "wallet_next_block_production_timestamp": null
}


[13:43:35] Emil Velichkov: this is with the checkpoints
[13:43:50] Emil Velichkov: note that 84.238.140.192:42577 is the seed node which is on the right chain
[13:44:18] Emil Velichkov: so checkpoints and --resync-blockchain does NOT work

[monsterer]

If as delegate you has a problems to sync to right chain, you should move to 0.4.27 and add following lines to checkpoints.json at data directory:

I have no file called checkpoints.json

Oh, it gets created when you run the client... which means you are forced to re-index once and then again if it doesn't work.

Yes, first time my 0.4.27 goes to wrong chain then I modify checkpoint.json and re-index.

Code: [Select]

./bitshares_client --rebuild-index

[testz]

If as delegate you has a problems to sync to right chain, you should move to 0.4.27 and add following lines to checkpoints.json at data directory:

I have no file called checkpoints.json

Oh, it gets created when you run the client... which means you are forced to re-index once and then again if it doesn't work.

Yes, first time my 0.4.27 goes to wrong chain then I modify checkpoint.json and re-index.

[monsterer]

If as delegate you has a problems to sync to right chain, you should move to 0.4.27 and add following lines to checkpoints.json at data directory:

I have no file called checkpoints.json

Oh, it gets created when you run the client... which means you are forced to re-index once and then again if it doesn't work.

[monsterer]

If as delegate you has a problems to sync to right chain, you should move to 0.4.27 and add following lines to checkpoints.json at data directory:

I have no file called checkpoints.json

[dannotestein]

If as delegate you has a problems to sync to right chain, you should move to 0.4.27 and add following lines to checkpoints.json at data directory:

  ],[
    1279500,
    "488313d2c1c85bdec117bac0379f7b17f7cfbed3"
  ],[
    1283300,
    "cef871ef96c687b4841b02a7643c2a90d6c46bd1"
  ],[
    1283590,
    "d5265058f7be7d5cf1b496bbaa9b9deaf8cfbe00"
  ]

I mark as bold the lines which present in original file.
After this you should re-index the database.

good idea, testz, that will make sure the client moves to the proper fork.

[testz]

If as delegate you has a problems to sync to right chain, you should move to 0.4.27 and add following lines to checkpoints.json at data directory:

  ],[
    1279500,
    "488313d2c1c85bdec117bac0379f7b17f7cfbed3"
  ],[
    1283300,
    "cef871ef96c687b4841b02a7643c2a90d6c46bd1"
  ],[
    1283590,
    "d5265058f7be7d5cf1b496bbaa9b9deaf8cfbe00"
  ]

I mark as bold the lines which present in original file.
After this you should re-index the database.

[liondani]

Some  (but not all) 4.26 delegates appear to be going off on a minority fork, so please upgrade to 0.4.27 as soon as you're able (especially if you're not on the majority fork).

Also, if you're on the wrong fork, you will probably need to delete your local copy of blockchain and resync.

Are you part of the official dev team?

yes he is.

http://bitshares.org/team/

[liondani]

just to keep this thread on the first places ...

(wallet closed) >>> info
{
  "blockchain_head_block_num": 1283702,
  "blockchain_head_block_age": "28 seconds old",
  "blockchain_head_block_timestamp": "2014-12-17T09:23:50",
  "blockchain_average_delegate_participation": "64.74 %",
  "blockchain_confirmation_requirement": 71,
  "blockchain_share_supply": "2,498,424,750.89030 BTS",
  "blockchain_blocks_left_in_round": 8,
  "blockchain_next_round_time": "at least 72 seconds in the future",
  "blockchain_next_round_timestamp": "2014-12-17T09:25:30",
  "blockchain_random_seed": "0d395d1024ac74ebe6a3725cacc0dfb358b02dfc",
  "client_data_dir": "/root/.BitShares",
  "client_version": "v0.4.26",
  "network_num_connections": 77,
  "network_num_connections_max": 200,

[monsterer]

Some  (but not all) 4.26 delegates appear to be going off on a minority fork, so please upgrade to 0.4.27 as soon as you're able (especially if you're not on the majority fork).

Also, if you're on the wrong fork, you will probably need to delete your local copy of blockchain and resync.

Are you part of the official dev team?

[liondani]

my seed node 185.25.22.21:1776 is on the right fork....

(wallet closed) >>> info
{
  "blockchain_head_block_num": 1283659,
  "blockchain_head_block_age": "6 seconds old",
  "blockchain_head_block_timestamp": "2014-12-17T09:13:30",
  "blockchain_average_delegate_participation": "65.58 %",
  "blockchain_confirmation_requirement": 76,
  "blockchain_share_supply": "2,498,424,447.19030 BTS",
  "blockchain_blocks_left_in_round": 51,
  "blockchain_next_round_time": "at least 8 minutes in the future",
  "blockchain_next_round_timestamp": "2014-12-17T09:22:00",
  "blockchain_random_seed": "03d4d1e27e7d8027c9182138b552da4ccbe733a4",
  "client_data_dir": "/root/.BitShares",
  "client_version": "v0.4.26",
  "network_num_connections": 78,
  "network_num_connections_max": 200,

[Harvey]

upgraded to 0.4.27

[liondani]

on the way !!!

[dannotestein]

Update, use client below for best results:
https://github.com/BitShares/bitshares/releases/tag/v0.4.27.1

Some  (but not all) 4.26 delegates appear to be going off on a minority fork, so please upgrade to 0.4.27 as soon as you're able (especially if you're not on the majority fork).

Also, if you're on the wrong fork, you will probably need to delete your local copy of blockchain and resync.
Also, as per msgs further down in this thread, if you fail to get on correct fork, you can force it using this method from testz:

If as delegate you have a problem to sync to right chain, you should move to 0.4.27.1 and add following lines to checkpoints.json at data directory:
Quote

      ],[
        1279500,
        "488313d2c1c85bdec117bac0379f7b17f7cfbed3"
      ],[
        1283300,
        "cef871ef96c687b4841b02a7643c2a90d6c46bd1"
      ],[
        1283590,
        "d5265058f7be7d5cf1b496bbaa9b9deaf8cfbe00"
      ]


I mark as bold the lines which present in original file.
After this you should re-index the database.