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