Other > DevShares

DevShares forked...

<< < (2/2)

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

wackou:

--- Quote from: davidpbrown on March 18, 2015, 01:06:08 pm ---Also, it's not helpful that init's are not broadcasting their version.. perhaps they've upgraded to v0.7.0??

--- End quote ---

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)

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

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

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?

Navigation

[0] Message Index

[*] Previous page