Test Net for Advanced Users

[betax]

So the real question is, why were we missing so many blocks?   Who got voted in and why did you stop producing?

BM please check my comment on Github. https://github.com/cryptonomex/graphene/issues/247#issuecomment-132349244
Once a witness started forking, it's hard to switch back.

I could not rejoin to the network after many errors... abit Ill try yours later on.

[clayop]

So the real question is, why were we missing so many blocks?   Who got voted in and why did you stop producing?

This severe problem may start from my witness. After I ran spam transactions with my witness account (I entered over 1000 txs in a moment), many witnesses including mine began to experience "Last block was generated by the same witness" problem.

[cryptosile]

Just woke up,
tried to restart withe the --checkpoint option , have a mix of not producing because we are stale and then some serving up block.  pretty sure it's not right...  I won't be able to change anything until late tonight.

Code: [Select]

530999ms th_a       witness.cpp:240               block_production_loo ] slot: 21412 scheduled_witness: 1.6.5249 scheduled_time: 2015-08-20T13:08:51 now: 2015-08-20T13:08:51
530999ms th_a       witness.cpp:211               operator()           ] Not producing block because production is disabled until we receive a recent block (see: --enable-stale-production)
531999ms th_a       witness.cpp:240               block_production_loo ] slot: 21413 scheduled_witness: 1.6.5246 scheduled_time: 2015-08-20T13:08:52 now: 2015-08-20T13:08:52
532999ms th_a       witness.cpp:240               block_production_loo ] slot: 21414 scheduled_witness: 1.6.0 scheduled_time: 2015-08-20T13:08:53 now: 2015-08-20T13:08:53
533999ms th_a       witness.cpp:240               block_production_loo ] slot: 21415 scheduled_witness: 1.6.1536 scheduled_time: 2015-08-20T13:08:54 now: 2015-08-20T13:08:54
534999ms th_a       witness.cpp:240               block_production_loo ] slot: 21416 scheduled_witness: 1.6.5245 scheduled_time: 2015-08-20T13:08:55 now: 2015-08-20T13:08:55
535999ms th_a       witness.cpp:240               block_production_loo ] slot: 21417 scheduled_witness: 1.6.1525 scheduled_time: 2015-08-20T13:08:56 now: 2015-08-20T13:08:56
536999ms th_a       witness.cpp:240               block_production_loo ] slot: 21418 scheduled_witness: 1.6.1 scheduled_time: 2015-08-20T13:08:57 now: 2015-08-20T13:08:57
537604ms th_a       application.cpp:487           get_blockchain_synop ] reference_point: 0000000000000000000000000000000000000000 number_of_blocks_after_reference_point: 0 result: ["00001fc61a621678e92fc941b58b08d13afa2268","00005fc6559ab7b6f2b0035b0accec1ca7bb9110","00007fc615d686c893fe81c7b3790565bd3ccac3","00008fc6ef374fa2e6b8a03a490dfc6f274d1b8c","000097c68746555744ecea0a5753eabbb540cb4b","00009bc6d4d50fefd8cca7e61cf243a1820d8add","00009dc666f08e568fddfe6ef99968363b649c16","00009ec6b4958ad1910cfd3d3d5451634b8c948a","00009f46f5a6a32bbe673fb3990ae69d80d29779","00009f863b8da93c16cd47c9a591d7a9071e92e1","00009fa6414eb1adf2e7a4e0ec81fa58bb2f0802","00009fb612985adcce921f4e1e47326e45b088dd","00009fbe0bbfc979683d479ba4abd6242dd0b7b0","00009fc2c4081a76afbad31337249726a2d06515","00009fc4a66df9d134e85476353bae7af2715909","00009fc50fe983dde2e975f6aed7d69f4f2cd952","00009fc6d4e24db66e13af461b94063165999bfa"]
537999ms th_a       witness.cpp:240               block_production_loo ] slot: 21419 scheduled_witness: 1.6.4435 scheduled_time: 2015-08-20T13:08:58 now: 2015-08-20T13:08:58
538115ms th_a       application.cpp:487           get_blockchain_synop ] reference_point: 00009cb4e54f640a0cef1aeab7aab0dfc955d333 number_of_blocks_after_reference_point: 0 result: ["00001fc61a621678e92fc941b58b08d13afa2268","00005fc6559ab7b6f2b0035b0accec1ca7bb9110","00007fc615d686c893fe81c7b3790565bd3ccac3","00008fc6ef374fa2e6b8a03a490dfc6f274d1b8c","000097c68746555744ecea0a5753eabbb540cb4b","00009bc6d4d50fefd8cca7e61cf243a1820d8add","00009dc666f08e568fddfe6ef99968363b649c16","00009ec6b4958ad1910cfd3d3d5451634b8c948a","00009f46f5a6a32bbe673fb3990ae69d80d29779","00009f863b8da93c16cd47c9a591d7a9071e92e1","00009fa6414eb1adf2e7a4e0ec81fa58bb2f0802","00009fb612985adcce921f4e1e47326e45b088dd","00009fbe0bbfc979683d479ba4abd6242dd0b7b0","00009fc2c4081a76afbad31337249726a2d06515","00009fc4a66df9d134e85476353bae7af2715909","00009fc50fe983dde2e975f6aed7d69f4f2cd952","00009fc6d4e24db66e13af461b94063165999bfa"]
538276ms th_a       application.cpp:438           get_item             ] Request for item {"item_type":1001,"item_hash":"00009cb5f3657547f191efd666aa7aaca57b3a8f"}
538276ms th_a       application.cpp:446           get_item             ] Serving up block #40117
538276ms th_a       application.cpp:438           get_item             ] Request for item {"item_type":1001,"item_hash":"00009cb5f3657547f191efd666aa7aaca57b3a8f"}
538276ms th_a       application.cpp:446           get_item             ] Serving up block #40117
538467ms th_a       application.cpp:487           get_blockchain_synop ] reference_point: 00009cb4e54f640a0cef1aeab7aab0dfc955d333 number_of_blocks_after_reference_point: 0 result: ["00001fc61a621678e92fc941b58b08d13afa2268","00005fc6559ab7b6f2b0035b0accec1ca7bb9110","00007fc615d686c893fe81c7b3790565bd3ccac3","00008fc6ef374fa2e6b8a03a490dfc6f274d1b8c","000097c68746555744ecea0a5753eabbb540cb4b","00009bc6d4d50fefd8cca7e61cf243a1820d8add","00009dc666f08e568fddfe6ef99968363b649c16","00009ec6b4958ad1910cfd3d3d5451634b8c948a","00009f46f5a6a32bbe673fb3990ae69d80d29779","00009f863b8da93c16cd47c9a591d7a9071e92e1","00009fa6414eb1adf2e7a4e0ec81fa58bb2f0802","00009fb612985adcce921f4e1e47326e45b088dd","00009fbe0bbfc979683d479ba4abd6242dd0b7b0","00009fc2c4081a76afbad31337249726a2d06515","00009fc4a66df9d134e85476353bae7af2715909","00009fc50fe983dde2e975f6aed7d69f4f2cd952","00009fc6d4e24db66e13af461b94063165999bfa"]



[clayop]

Actually there is a trick to restarting block production after so much time has passed.

First add a the following checkpoint

[HEADNUM+1, "00000000.....00"]

With that checkpoint you will be able to produce the next block.   Once you have produced the block, other nodes can add a checkpoint with that freshly produced block and you will be up and running again.

Every time a checkpoint is reached it resets the required undo history to 0.  Adding a checkpoint at HEADNUM will reset it to 0, but the next block you produce will have missed over 1000 blocks so is immediately beyond the reach.  Therefore, we need to "checkpoint" the "next block" for which we do not know the ID yet.   

So the real question is, why were we missing so many blocks?   Who got voted in and why did you stop producing?

Witnesses please add this so we can go on:

Code: [Select]

--checkpoint '[40903,"00009fc7e518d750f653ba0ca25a3067bd304f30"]'

//Update: 1000 seconds have passed so quickly. Rescue failed. Have to wait until enough witnesses come online.

Failed to push new blocks. What is exact command?

Code: [Select]

619838ms th_a       db_block.cpp:170              _push_block          ] Failed to push new
block:
10 assert_exception: Assert Exception
next_block.id() == itr->second: Block did not match checkpoint
    {"checkpoint":[40903,"00009fc7e518d750f653ba0ca25a3067bd304f30"],"block_id":"00009fc7481
4ff846dcfa61cd7a48913d775d971"}
    th_a  db_block.cpp:367 apply_block
Segmentation fault (core dumped)

[abit]

For those who have interest, I started another chain. Chain id is still "5508f5f743717fe2c78445364f62a72badd7532974d26f089af2062228b532eb"

Code: [Select]

./witness_node -s 114.92.254.159:62015  --genesis-json aug-19-puppies-test-genesis.json


[abit]

So the real question is, why were we missing so many blocks?   Who got voted in and why did you stop producing?

BM please check my comment on Github. https://github.com/cryptonomex/graphene/issues/247#issuecomment-132349244
Once a witness started forking, it's hard to switch back.

[abit]

Actually there is a trick to restarting block production after so much time has passed.

First add a the following checkpoint

[HEADNUM+1, "00000000.....00"]

With that checkpoint you will be able to produce the next block.   Once you have produced the block, other nodes can add a checkpoint with that freshly produced block and you will be up and running again.

Every time a checkpoint is reached it resets the required undo history to 0.  Adding a checkpoint at HEADNUM will reset it to 0, but the next block you produce will have missed over 1000 blocks so is immediately beyond the reach.  Therefore, we need to "checkpoint" the "next block" for which we do not know the ID yet.   

So the real question is, why were we missing so many blocks?   Who got voted in and why did you stop producing?

Witnesses please add this so we can go on:

Code: [Select]

./witness_node ...... --checkpoint '[40903,"00009fc7e518d750f653ba0ca25a3067bd304f30"]'
[/s]
//Update: 1000 seconds have passed so quickly. Rescue failed. Have to wait until enough witnesses come online.

[bytemaster]

My node is online now. Witness id 1.6.5247.
But number of active witnesses is still 10?

Code: [Select]

{
  "head_block_num": 11773,
  "head_block_id": "00002dfdab35043defebc42a6ae9d5a96767fd97",
  "head_block_age": "1 second old",
  "next_maintenance_time": "82 seconds in the future",
  "chain_id": "5508f5f743717fe2c78445364f62a72badd7532974d26f089af2062228b532eb",
  "active_witnesses": [
    "1.6.0",
    "1.6.1",
    "1.6.2",
    "1.6.3",
    "1.6.4",
    "1.6.5",
    "1.6.6",
    "1.6.1525",
    "1.6.4435",
    "1.6.5246",
    "1.6.5247"
  ],
  "active_committee_members": [
    "1.5.0",
    "1.5.1",
    "1.5.2",
    "1.5.3",
    "1.5.4",
    "1.5.5",
    "1.5.6",
    "1.5.7",
    "1.5.8",
    "1.5.9"
  ],
  "entropy": "73f47170212775453a20de79b10d927e9d3b761d"
}


for some reason the info and get_global_properties screen dont show all witnesses.  There may have been something I should have changed in the genesis.  There are 101 delegate slots though.

By looking at the screen of witness_node, it's true that only the 11 witnesses are producing blocks.

//Edit: it's 11, not 10

Yeah.  You're right.

Thats funny because I had 100 going earlier.  I could tell because I set the genesis to 101, but set my server witness node to 100, and so 1.6.100 was missing blocks every single rotation.

This is because the blockchain has a MIN WITNESS count of 11, to get more than 11 requires the majority of the voting stake to actively vote for more than 11.  So once people started voting "just for their witness" it quickly reverted back to 11. 

[bytemaster]

Actually there is a trick to restarting block production after so much time has passed.

First add a the following checkpoint

[HEADNUM+1, "00000000.....00"]

With that checkpoint you will be able to produce the next block.   Once you have produced the block, other nodes can add a checkpoint with that freshly produced block and you will be up and running again.

Every time a checkpoint is reached it resets the required undo history to 0.  Adding a checkpoint at HEADNUM will reset it to 0, but the next block you produce will have missed over 1000 blocks so is immediately beyond the reach.  Therefore, we need to "checkpoint" the "next block" for which we do not know the ID yet.   

So the real question is, why were we missing so many blocks?   Who got voted in and why did you stop producing?

[mudshark79]

I think it should be useful if slot < 1000. But we've missed more than 10000 blocks already.

Code: [Select]

1117002ms th_a       witness.cpp:240               block_production_loo ] slot: 14798 scheduled_witness: 1.6.1 scheduled_time: 2015-08
-20T11:18:37 now: 2015-08-20T11:18:37
1118002ms th_a       witness.cpp:240               block_production_loo ] slot: 14799 scheduled_witness: 1.6.5248 scheduled_time: 2015
-08-20T11:18:38 now: 2015-08-20T11:18:38
1119002ms th_a       witness.cpp:240               block_production_loo ] slot: 14800 scheduled_witness: 1.6.5247 scheduled_time: 2015-08-20T11:18:39 now: 2015-08-20T11:18:39
1119002ms th_a       witness.cpp:243               block_production_loo ] Witness 1.6.5247 production slot has arrived; generating a block now...
1119004ms th_a       db_block.cpp:170              _push_block          ] Failed to push new block:
3070000 undo_database_exception: undo database exception

At least it gives an exception now that it tried... don't think it should correlate with the number. 1000 seems to be the limit without checkpoint or so.. but really just guessing.
Going standby for the next attempt....

[abit]

Did it get you going again? Seems to be still stuck or maybe you are on your own fork now? Which is your adress to use as seed-node?

I'm sure that I'm not on my own fork. Check this: http://45.55.6.216:8080/#/explorer/blocks or try 'info' command in cliwallet, my result is:

Code: [Select]

new >>> info
info
{
  "head_block_num": 40902,
  "head_block_id": "00009fc6d4e24db66e13af461b94063165999bfa",
  "head_block_age": "4 hours old",
  "next_maintenance_time": "4 hours ago",
  "chain_id": "5508f5f743717fe2c78445364f62a72badd7532974d26f089af2062228b532eb",
...
}


OK, I see. So starting the witness-node with Checkpoint didn't make a difference then?

I think it should be useful if slot < 1000. But we've missed more than 10000 blocks already.

Code: [Select]

1117002ms th_a       witness.cpp:240               block_production_loo ] slot: 14798 scheduled_witness: 1.6.1 scheduled_time: 2015-08
-20T11:18:37 now: 2015-08-20T11:18:37
1118002ms th_a       witness.cpp:240               block_production_loo ] slot: 14799 scheduled_witness: 1.6.5248 scheduled_time: 2015
-08-20T11:18:38 now: 2015-08-20T11:18:38
1119002ms th_a       witness.cpp:240               block_production_loo ] slot: 14800 scheduled_witness: 1.6.5247 scheduled_time: 2015-08-20T11:18:39 now: 2015-08-20T11:18:39
1119002ms th_a       witness.cpp:243               block_production_loo ] Witness 1.6.5247 production slot has arrived; generating a block now...
1119004ms th_a       db_block.cpp:170              _push_block          ] Failed to push new block:
3070000 undo_database_exception: undo database exception


[abit]

General question (since I could not find this elsewhere):

Is there a genuine place from where I can download "an up-to-date" BitShares blockchain? Setting up a new client is easy, but syncing it takes long and sometimes does not work such that the whole process needs to be repeated again and again (my slow little pc, c847/8gb, often has problems here and it takes days to re-sync/re-download the chain)... As such, it would be awesome to have an official and always "up-to-date" download link for the BitShares blockchain.

That said, my question is if such a download link is already there (and I could not find it), or would it be a great addition to the BitShare's homepage?

EDIT: Also 8gb ram seem sometimes not enough for a re-sync (using v0.9.2)... is that true? Did some one else make similar experiences?

I don't know if there is a download link for the blockchain.
8GB RAM is more than enough. If you're using Windows or Linux, try run  'bitshares_client' rather than GUI for initial syncing. After in-sync you can press ctrl+d to close it then open GUI.
Wish you good luck.

[mudshark79]

Did it get you going again? Seems to be still stuck or maybe you are on your own fork now? Which is your adress to use as seed-node?

I'm sure that I'm not on my own fork. Check this: http://45.55.6.216:8080/#/explorer/blocks or try 'info' command in cliwallet, my result is:

Code: [Select]

new >>> info
info
{
  "head_block_num": 40902,
  "head_block_id": "00009fc6d4e24db66e13af461b94063165999bfa",
  "head_block_age": "4 hours old",
  "next_maintenance_time": "4 hours ago",
  "chain_id": "5508f5f743717fe2c78445364f62a72badd7532974d26f089af2062228b532eb",
...
}


OK, I see. So starting the witness-node with Checkpoint didn't make a difference then?

[abit]

Did it get you going again? Seems to be still stuck or maybe you are on your own fork now? Which is your adress to use as seed-node?

I'm sure that I'm not on my own fork. Check this: http://45.55.6.216:8080/#/explorer/blocks or try 'info' command in cliwallet, my result is:

Code: [Select]

new >>> info
info
{
  "head_block_num": 40902,
  "head_block_id": "00009fc6d4e24db66e13af461b94063165999bfa",
  "head_block_age": "4 hours old",
  "next_maintenance_time": "4 hours ago",
  "chain_id": "5508f5f743717fe2c78445364f62a72badd7532974d26f089af2062228b532eb",
...
}


[brainbug]

General question (since I could not find this elsewhere):

Is there a genuine place from where I can download "an up-to-date" BitShares blockchain? Setting up a new client is easy, but syncing it takes long and sometimes does not work such that the whole process needs to be repeated again and again (my slow little pc, c847/8gb, often has problems here and it takes days to re-sync/re-download the chain)... As such, it would be awesome to have an official and always "up-to-date" download link for the BitShares blockchain.

That said, my question is if such a download link is already there (and I could not find it), or would it be a great addition to the BitShare's homepage?

EDIT: Also 8gb ram seem sometimes not enough for a re-sync (using v0.9.2)... is that true? Did some one else make similar experiences?