BitShares Forum
Other => Graveyard => DevShares => Topic started by: wackou on March 18, 2015, 12:44:21 pm
-
It looks like all the init delegates went on their own fork, leaving all the others on a minority fork... See http://dvs.bitsharesblocks.com/
How do we solve this? Should the init delegates sort it out themselves or do we (the other delegates) have to do something to get back on the fork from the init delegates?
-
Well spotted..
I don't know how this would have occurred but wonder that in future the majority fraction could be broadcasting their checkpoints regularly in a way that others could note those in the checkpoints.json when there is a fork. Perhaps that could even be automatically fixing such forks?
I haven't got a GUI running atm to see if that is holding to the major branch and could give the checkpoint for us to adopt. I have asked a couple of times what the procedure is for fixing a fork but haven't seen a clear answer. I guess we wait for devs to confirm a checkpoint or a fix. :-\
-
Also, it's not helpful that init's are not broadcasting their version.. perhaps they've upgraded to v0.7.0??
-
Also, it's not helpful that init's are not broadcasting their version.. perhaps they've upgraded to v0.7.0??
agreed, init delegates should broadcast their version, at least for us to know whether something is off with them or if the fork is a "natural" one... It's not related to 0.7.0 as this is a new BitShares version, unrelated to DevShares. The current version of DevShares about to be released (previously 0.7.0) will be renamed 0.8.0 (The current bts tag should have been 0.6.4, but as it contained a hardfork, the version number has been bumped)
-
We'll take a look. For now, just assume the init delegates are on the wrong fork.
-
I am on a 26% participation fork (it was at 40% without the init delegates), does it mean everybody is switching to the init delegates fork now? I thougt we would insist to stay there... have I missed something? Should I try to connect to another fork? what is your participation guys?
-
"blockchain_head_block_num": 621266,
"blockchain_head_block_timestamp": "2015-03-26T10:11:30",
"blockchain_average_delegate_participation": "29.19 %",
:-\
I don't know if it's possible to see the breakdown of the forking and the %'s each fraction holds. I've assumed for most of these that it's one major, one minor but at 29% there's a risk of being on the wrong one, even if as vikram suggested the major init fork is wrong and the next biggest is true. I guess at 29% I'm on the best one now.
I'm not quite expert at this yet but perhaps you can check or force your block hash to be the same as mine.
blockchain_get_blockhash 621266 => "b5b5ae9b169267e05b1871a783d4a1b22e56b52e"
I would expect that one way to jump chains is to put that hash into the checkpoint.json and start again with --rebuild-index but that could become complicated if you have more than one correction to the normal in that.. but I might be wrong if that blockchain_get_blockhash is giving the init major fork hash and not the hash for the fork I'm on..??.. if it only replies with major fork detail, then I guess that change will not have any effect until the fork is fixed.
-
In case it is useful.. now seeing 35.69 %
"blockchain_head_block_num": 621583,
"blockchain_head_block_timestamp": "2015-03-26T12:37:30",
"blockchain_average_delegate_participation": "35.69 %",
blockchain_get_blockhash 621583 => "1785f9ddc04f006207b16db38cae0ebf8bf2ebd7"
-
Checking mine for participation, I've just found it had crashed and restart then gave error:
Loading blockchain from: /home/devshares/.DevShares/chain
Loading config from file: /home/devshares/.DevShares/config.json
Using blockchain checkpoints from file: /home/devshares/.DevShares/checkpoints.json
------------ error --------------
10 assert_exception: Assert Exception
is_open(): Database is not open!
{}
th_a level_map.hpp:344 create_batch
{}
th_a cached_level_map.hpp:52 flush
{}
th_a cached_level_map.hpp:28 close
{}
th_a chain_database.cpp:1542 close
{"data_dir":"/home/devshares/.DevShares/chain"}
th_a chain_database.cpp:1488 open
{"data_dir":"/home/devshares/.DevShares"}
th_a client.cpp:1347 open
First time I've seen a crash like that.
I could do with having a method to get email when the server falls over but haven't had time to figure that out.
Above looks fixed by running rebuild:
./devshares_client --rebuild-index
-
Also on this chain:
main (unlocked) >>> blockchain_get_blockhash 621266
"b5b5ae9b169267e05b1871a783d4a1b22e56b52e"
40.08% delegate participation