Author Topic: DevShares forked...  (Read 5874 times)

0 Members and 1 Guest are viewing this topic.

Offline cryptosile

  • Full Member
  • ***
  • Posts: 56
    • View Profile
Also on this chain:

main (unlocked) >>> blockchain_get_blockhash 621266
"b5b5ae9b169267e05b1871a783d4a1b22e56b52e"

40.08% delegate participation

Offline davidpbrown

Checking mine for participation, I've just found it had crashed and restart then gave error:

Quote
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:
Quote
./devshares_client --rebuild-index

฿://1CBxm54Ah5hiYxiUtD7JGYRXykT5Z6ZuMc

Offline davidpbrown

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"
฿://1CBxm54Ah5hiYxiUtD7JGYRXykT5Z6ZuMc

Offline davidpbrown

  "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.
« Last Edit: March 26, 2015, 10:23:52 am by davidpbrown »
฿://1CBxm54Ah5hiYxiUtD7JGYRXykT5Z6ZuMc

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
 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?

Offline vikram

We'll take a look. For now, just assume the init delegates are on the wrong fork.

Offline wackou

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)
Please vote for witness wackou! More info at http://digitalgaia.io

Offline davidpbrown

Also, it's not helpful that init's are not broadcasting their version.. perhaps they've upgraded to v0.7.0??
฿://1CBxm54Ah5hiYxiUtD7JGYRXykT5Z6ZuMc

Offline davidpbrown

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.  :-\
฿://1CBxm54Ah5hiYxiUtD7JGYRXykT5Z6ZuMc

Offline wackou

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?
Please vote for witness wackou! More info at http://digitalgaia.io