Quote from: onsightit on November 11, 2016, 03:28:59 PM

Quote from: solarcoiner on November 11, 2016, 01:23:00 PM

Quote from: y_virtual on November 11, 2016, 08:32:28 AM

Quote from: onsightit on November 10, 2016, 06:21:02 PM

All,

We have just issued version 2.1.7, protocol version 70005, to fix the problem described below:

"The reduced txn fee change caused 2.1.1 nodes to fork because 2.1.6 nodes were not paying enough fees. This in turn caused 2.1.6 nodes to fork sporadically."

Please update your Qt wallet ASAP and begin staking so we can get the network moving again.

Note: This update requires a Blockchain Reload. This is due to the fact that some 2.1.6 nodes are ahead of the master node, and we want to get everyone one the correct chain. After the reload, please rescan your wallet. If you are running a daemon, you can download the bootstrap.zip here: http://blockexplorer.solarcoin.org/downloads/bootstrap.zip

PS: We will be notifying the exchanges and explorer ASAP. The website will be updated later today.

PPS: After the rescan, you may see conflicted transactions from earned interest. You will make up the "lost" interest in future stakes.

Hi Steve,

Please let us know when the Explorer has been updated, so that we are sure we have the correct height there to compare to. Thanks!

Yes I was also thinking about that. How do we really know what the real chain is? How do we even know the explorer is on the right chain. Since everyone was on a fork how can we tell?

The CryptoID explorer was updated to 2.1.7 yesterday. It is on the same block as the masternode, and we are watching it. The 2.1.7 wallet is on protocol version 70005 and will block any nodes on 70004, so if you are still having syncing issues, please reload the blockchain and rescan your wallet. That works 99.9% of the time, but if not, shut down the wallet, remove your peers.dat and make sure the only addnode in your wallet config is: addnode=162.243.214.120

Also, please ensure that the clock on your computer is set accurately. This is known to cause some nodes to have trouble syncing.

Thanks, for your patience.

-Steve

I have been encountering the same issue as reported in the several previous posts - after upgrading to 2.1.7 and running fine for just a while, I am not able anymore to correctly sync any of 6 wallets on 4 machines (also tried connecting through my 4G internet provider to get a brand new IP address thus eliminate possible banning issues, but the result was the same).
There are 2 issues I noticed:
1 - the wallet "decides" it has synced (changes its status to In Sync) the moment it encounters a new connection with a lower startingheight than it's own, or lower than the previous higher height connections it found (I am using the getpeerinfo command from the Console). The wallet then (syncs to) and starts staking at that lower block height (if the total number of connections at that time is >= 3). Then only if it gets a new connection with a higher than it's own block height, it goes to Syncing mode but no blocks get further downloaded (see issue 2 below).
2 - the wallet remains in the state "Syncing" no matter how many connections with a higher startingheight it has. Then later on as soon as it gets accidentally a new connection to a node with a lower startingheight (than it's own or the previously found higher height connections) , it goes to issue 1 above. If the total number of connections at that time is >= 3, it even starts staking at that lower block height.

Right now I have re-loaded the blockchain from the newest bootstrap, up to block 1455297, and trying to sync from there on. I have snapshots of both issues, if needed.

Isn't the protocol originally supposed to choose the highest blockchain? Why does it decide to have synced and starts staking only when it finds a connection with a block height lower than the previously found? Was there any "hot-fix" change made to the basic-level consensus protocol so that the 2.1.6 -> 2.1.7 transition gets propagated faster?