Dry Run 4: A New Hope

[toast]

Thanks everyone!
We are going to reset to test out the new ~Approval Voting~! Hooray!

[sudo]

Code Select Expand

>> blockchain_list_forks

[
  777,
  811,
  818,
  853,
  872,
  874,
  900,
  944,
  1178,
  1219,
  2147,
  2148,
  2149
]
>> about

{
  "bitshares_toolkit_revision": "9de0540ba6b911560ae0ab0fe2fe9b8d83a7d4ec",
  "bitshares_toolkit_revision_age": "65 hours ago",
  "fc_revision": "331e6aac7d1ac7a6fd7c0b0fa092099eb25c99a1",
  "fc_revision_age": "73 hours ago",
  "compile_date": "compiled on Jun 20 2014 at 17:08:18"
}

[clout]

how do you specify where you want votes to go from a given transaction? or can you not override the wallets automated allocation of votes?

[alt]

sorry I miss the version information.
I can get info from console.log.
this show I run client from 20140622T000013
and I think I must pull code and build before this time.

Code Select Expand


info
{
  "blockchain_head_block_num": 1935,
  "blockchain_head_block_time": "20140621T235930",
  "blockchain_head_block_time_rel": "43 seconds old",
  "blockchain_confirmation_requirement": 299,
  "blockchain_average_delegate_participation": 60.953530476765238,
  "network_num_connections": 0,
  "ntp_time": "20140622T000013.254594",
  "ntp_error_seconds": -0.0028019999999999998,
  "wallet_unlocked_seconds_remaining": 99999998,
  "wallet_next_block_production_time": "20140622T000530",
  "wallet_seconds_until_next_block_production": 317,
  "wallet_local_time": "20140622T000013",
  "blockchain_random_seed": "615f964e82892c016eafbfafd924fbef7ead51cd",
  "blockchain_shares": 9997580403788,
  "network_num_connections_max": 999,
  "network_protocol_version": 103,
  "wallet_open": true,
  "wallet_unlocked_until": "20170822T094651",
  "wallet_version": 100
}


[vikram]

some fork happend strange.
Just now, I found my delegate alt && dorian begin to miss  block.
So I wait until next block generate.
first I see the block generate normaly, block ID is 4231.
after a minutes, when block 4232 is sync.
I check block 4231 again, it's different with before, means dorian create  block 4231 but refuse by the main chain.
dorian  lose block 4176 && 423,  at that time,  forked occured at 4174 && 4229.
after restart the client, everything is ok now.

Code Select Expand


delegate (unlocked) >>> blockchain_get_delegate_block_stats 299
....
  ],[
    4130,{
      "missed": false,
      "latency": 0
    }
  ],[
    4176,{
      "missed": true,
      "latency": null
    }
  ],[
    4231,{
      "missed": true,
      "latency": null
    }
  ]
]


Code Select Expand


delegate (unlocked) >>> blockchain_list_forks
....
  4174,
  4180,
  4182,
  4218,
  4227,
  4229
]


What is output of 'about' command?

[taoljj]

some fork happend strange.
Just now, I found my delegate alt && dorian begin to miss  block.
So I wait until next block generate.
first I see the block generate normaly, block ID is 4231.
...

I found dorian missed 2 blocks,art missed 1 block.

[alt]

some fork happend strange.
Just now, I found my delegate alt && dorian begin to miss  block.
So I wait until next block generate.
first I see the block generate normaly, block ID is 4231.
after a minutes, when block 4232 is sync.
I check block 4231 again, it's different with before, means dorian create  block 4231 but refuse by the main chain.
dorian  lose block 4176 && 423,  at that time,  forked occured at 4174 && 4229.
after restart the client, everything is ok now.

Code Select Expand


delegate (unlocked) >>> blockchain_get_delegate_block_stats 299
....
  ],[
    4130,{
      "missed": false,
      "latency": 0
    }
  ],[
    4176,{
      "missed": true,
      "latency": null
    }
  ],[
    4231,{
      "missed": true,
      "latency": null
    }
  ]
]


Code Select Expand


delegate (unlocked) >>> blockchain_list_forks
....
  4174,
  4180,
  4182,
  4218,
  4227,
  4229
]


[bytemaster]

Are you not confused by the double negative? 

It says the 307 didn't miss blocks 3667, 3731, or 3786.... and it also says that he is the one who signed it.  In other words, perfectly consistent.

I don't follow.

It says xeldal: 307 didn't miss block 3786 and yet says "batman" signed 3786  batman ID: 321  not 307

What am I missing?

from the last 8 entries in blockchain_get_delegate_block_stats the block number corresponds via blockchain_get_signing_delegate to 5 different delegates.  that's not consistent when I expect them to all be the same delegate.

Right... sorry I miss read it.

Looking at the code I found the cause... the blockchain_get_delegate_block_stats is likely wrong as a result of fork processing code.  This data is not used for block validation so is likely a cosmetic bug, but one that should be resolved none the less.  I will have vikram work on it tomorrow.

[bytemaster]

Are you not confused by the double negative? 

It says the 307 didn't miss blocks 3667, 3731, or 3786.... and it also says that he is the one who signed it.  In other words, perfectly consistent.

I don't follow.

It says xeldal: 307 didn't miss block 3786 and yet says "batman" signed 3786  batman ID: 321  not 307

What am I missing?

from the last 8 entries in blockchain_get_delegate_block_stats the block number corresponds via blockchain_get_signing_delegate to 5 different delegates.  that's not consistent when I expect them to all be the same delegate.

Right... sorry I miss read it.

[Xeldal]

Are you not confused by the double negative? 

It says the 307 didn't miss blocks 3667, 3731, or 3786.... and it also says that he is the one who signed it.  In other words, perfectly consistent.

I don't follow.

It says xeldal: 307 didn't miss block 3786 and yet says "batman" signed 3786  batman ID: 321  not 307

What am I missing?

from the last 8 entries in blockchain_get_delegate_block_stats the block number corresponds via blockchain_get_signing_delegate to 5 different delegates.  that's not consistent when I expect them to all be the same delegate.

[bytemaster]

inconsistency.
blockchain_get_delegate_block_stats shows results for many different delegates

307         xeldal 

xeldal-w (unlocked) >>> blockchain_get_delegate_block_stats 307
[[
...
  ],[
    3667,{
      "missed": false,
      "latency": 0
    }
  ],[
    3731,{
      "missed": false,
      "latency": 0
    }
  ],[
    3786,{
      "missed": false,
      "latency": 0
    }
  ]
]

xeldal-w (unlocked) >>> blockchain_get_signing_delegate 3667
"xeldal"
xeldal-w (unlocked) >>> blockchain_get_signing_delegate 3731
"xeldal"
xeldal-w (unlocked) >>> blockchain_get_signing_delegate 3786
"batman"

xeldal-w (unlocked) >>> about
{
  "bitshares_toolkit_revision": "24b41c1c879af8847d910572c3711b59e87053d9",
  "bitshares_toolkit_revision_age": "6 hours ago",
  "fc_revision": "3de924b33647a9a547b772a58415835f021f92b3",
  "fc_revision_age": "28 hours ago",
  "compile_date": "compiled on Jun 22 2014 at 15:35:42"
}

Are you not confused by the double negative? 

It says the 307 didn't miss blocks 3667, 3731, or 3786.... and it also says that he is the one who signed it.  In other words, perfectly consistent.

[puppies]

I've got the same results as Xeldal.  blockchain_get_delegate_block_stats 311 returns block 3593 with a "missed": false flag, but a blockchain_get_signing_delegate 3593 returns bitcoiners as the signing delegate. 

blockchain_get_delegate_block_stats 340 (bitcoiners) also shows block 3593, but has some blocks that show different names with blockchain_get_signing_delegate

[Xeldal]

inconsistency.
blockchain_get_delegate_block_stats shows results for many different delegates

307         xeldal 

xeldal-w (unlocked) >>> blockchain_get_delegate_block_stats 307
[[
...
  ],[
    3667,{
      "missed": false,
      "latency": 0
    }
  ],[
    3731,{
      "missed": false,
      "latency": 0
    }
  ],[
    3786,{
      "missed": false,
      "latency": 0
    }
  ]
]

xeldal-w (unlocked) >>> blockchain_get_signing_delegate 3667
"xeldal"
xeldal-w (unlocked) >>> blockchain_get_signing_delegate 3731
"xeldal"
xeldal-w (unlocked) >>> blockchain_get_signing_delegate 3786
"batman"

xeldal-w (unlocked) >>> about
{
  "bitshares_toolkit_revision": "24b41c1c879af8847d910572c3711b59e87053d9",
  "bitshares_toolkit_revision_age": "6 hours ago",
  "fc_revision": "3de924b33647a9a547b772a58415835f021f92b3",
  "fc_revision_age": "28 hours ago",
  "compile_date": "compiled on Jun 22 2014 at 15:35:42"
}

[bytemaster]

    "addr": "176.9.234.167:8763",
    "addr": "180.153.142.115:8764",

[Xeldal]

network_add_node "180.153.142.115:8764" add
network_add_node "162.243.127.243:33933" add
network_add_node "84.238.140.192:8763" add
network_add_node "107.170.30.182:8763" add
network_add_node "107.170.170.214:40767" add
network_add_node "107.170.211.129:48199" add
network_add_node "176.9.234.167:8763" add
network_add_node "107.170.30.182:8764" add
network_add_node "106.185.24.234:48807" add
network_add_node "58.246.76.58:54229" add
network_add_node "178.191.198.168:59448" add
network_add_node "162.243.153.227:8763" add
network_add_node "137.117.246.253:1024" add
network_add_node "106.185.26.162:8761" add
network_add_node "106.187.91.24:8763" add
network_add_node "216.252.204.39:8763" add
network_add_node "46.252.21.49:40653" add
network_add_node "120.43.49.199:58073" add

Edit: updated