vikram解决0.8.1分叉危机https://bitsharestalk.org/index.php?topic=15218.msg197141#msg197141
I haven't read the rest of the thread but the above is the primary problem, and is common whenever we hardfork because we get long minority chains from delegates who haven't updated.
There is also a second problem where blocks after the hardfork are not necessarily invalid for old clients. So they might upgrade after the hardfork and if they don't reindex, they will have an inconsistent state but cannot tell until they finally start rejecting blocks.
It seems like we can mitigate the most common issues by a combination of:
Force all blocks after a hardfork to be invalid for old clients
Always reindex for hardfork releases
Always release a version with a checkpoint right after the hardfork as soon as possible. And force a reindex on startup if any checkpoints dont match the current state
更改数据目录下:checkpiont.json,在头部加入最新区块数据。
linux下,启动时加上 --rebuild-index参数
节点:
addnode 69.90.132.209:1375 delegate.nathanhourt.com at
addnode 85.214.53.224:1375 fubly
addnode 185.25.22.21:1375 liondani
addnode 46.226.109.66:1375 wackou